Update and Delete API is confusing about skygear-sdk-js HOT 7 CLOSED

I believe query.equalTo("id", "note/d5a02b77-cc7a-4f93-8cb9-4806b3762767"); should be a valid query.

Let add a logic to translate it at SDK Query. The logic will make query.equalTo("id", "note/d5a02b77-cc7a-4f93-8cb9-4806b3762767"); become save result as query.equalTo("_id", "d5a02b77-cc7a-4f93-8cb9-4806b3762767");

Any concern? @cheungpat @ben181231

from skygear-sdk-js.

Should we have something like query.equalToID("note/d5a02b77-cc7a-4f93-8cb9-4806b3762767") ?

from skygear-sdk-js.

You don’t need to put an emphasis on the word “confusing” to convince me that this is confusing.

The intended usage for your illustrated scenario should be this:

let query = new skygear.Query(Note);
query.equalTo('_id', '123456...');

// for update
skygear.publicDB.query(query)
.then((records) => {
  let note = records[0]; // assuming there are more than one records, ditto for below
  note['content'] = 'Hello New World';
  return skygear.publicDB.save(note);
}).then(...);

// for delete
skygear.publicDB.query(query)
.then((records) => {
  let note = records[0];
  return skygear.publicDB.delete(note);
}).then(...);

To bring feature parity among SDKs, I think JS need a function to fetch a record by ID, if such function exists:

skygear.publicDB.fetchByIds(["note/123456..."])
.then((records) => {
  // do work here
})

This way, the user does not need to know the subtlety between _id (which is a field in the record dictionary) and id (which is a property in the JavaScript object).

We also need a deleteByIds function so that the developer does not need to create an Object just to delete a Record if the RecordID is known already, as in your delete example.

If you encounter a 500 error, please open a new issue with the way you access the server (sample code), and the details of the error you got from the server.

We might also want to consider warning the user if the passed in object in delete and save function is not of the expected type, but admittedly I am not familiar with JavaScript convention in this particular scenario.

from skygear-sdk-js.

fetchByIds and deleteByIds sound like a good solution.

const Note = skygear.Record.extend("note");
var query = new skygear.Query(Note);
query.equalTo("id", "note/d5a02b77-cc7a-4f93-8cb9-4806b3762767");
skygear.publicDB.query(query).then(...);

This code would produce the following error message.

{
    status: 500,
    error: {
        code: 10000,
        message: "pq: column note.id does not exist",
        name: "UnexpectedError"
    }
}

I guess it is not a big problem and it is related to this current issue of id vs _id, so I'm not sure if I should create a separate issue for this. Maybe we can change it to a 400 error and provide a better error message to inform the user that he is querying with a non-existing column/attribute.

from skygear-sdk-js.

@ben181231 does your suggestion include reject all equal with "id" or "_id"? I doubt it will too rigid. And tempted to add another equalToOtherMeta or createBefore methods.

from skygear-sdk-js.

@rickmak is it possible to create a record field called id?

from skygear-sdk-js.

No. skygear-server will return following at the moment:

{
    "error": {
        "code": 107, 
        "message": "fails to decode the request payload", 
        "name": "BadRequest"
    }
}

from skygear-sdk-js.