Closed Bug 1000831 Opened 10 years ago Closed 10 years ago

Prefer using insert()/update() than add()/put() for the DataStore interface.

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: airpingu, Assigned: baku)

References

Details

Attachments

(1 file)

The insert()/update() has a more explicit naming for its purpose and has a more clear error path (failing to call insert() means failed to insert; the same for update()). Mozilla's put()/add() is ambiguous because it can even call add() to update an existing record.

Hope to align this to the W3C version at: http://airpingu.github.io/data-store-api/index.html
Summary: Prefer using insert()/update() than add()/put() → Prefer using insert()/update() than add()/put() for the DataStore interface.
I think insert()/update() are better names. but if we change them, we break apps.
Ehsan, if we change them and then we write an email to platform and b2g mailing list, is it enough?
Flags: needinfo?(ehsan)
Attached patch update.patchSplinter Review
Attachment #8411786 - Flags: review?(ehsan)
I was not around when the API was being designed for the first time but to the best of my knowledge, these names were chosen for consistency with IndexedDB's IDBObjectStore methods, and I think that's a good argument in favor of the existing names.  The fact that the DataStore add function can be used to update the values is definitely odd and inconsistent with IDBObjectStore, so I would be more open to changing that.

Ben, Jonas, what do you think?

As far as when and how to make the change if we decide that we should do it at all, firstly I think we need to figure out exactly what things we want to change in the API, announce our plans in advance on dev-webapi and dev-gaia and then make all of the changes we want to make at once, with prior coordination with the Gaia teams that are using the API right now.  We should also make sure to make any changes that we want to make before we open up the API to third-party applications (which as far as I understand is a 2.0 goal.)  Given the fact that there are other problems with the API too, we should probably hold off here for now.
Flags: needinfo?(jonas)
Flags: needinfo?(ehsan)
Flags: needinfo?(bent.mozilla)
Comment on attachment 8411786 [details] [diff] [review]
update.patch

Clearing the review request while we decide whether we want to make this change.
Attachment #8411786 - Flags: review?(ehsan)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #3)
> As far as when and how to make the change if we decide that we should do it
> at all, firstly I think we need to figure out exactly what things we want to
> change in the API, announce our plans in advance on dev-webapi and dev-gaia
> and then make all of the changes we want to make at once, with prior
> coordination with the Gaia teams that are using the API right now.  We
> should also make sure to make any changes that we want to make before we
> open up the API to third-party applications (which as far as I understand is
> a 2.0 goal.)  Given the fact that there are other problems with the API too,
> we should probably hold off here for now.

Fortunately, insert()/update() are totally new name and DataStore API is not yet exposed to public (third-party apps) so we won't face too much pain about incompatibility issue. We may do:

1. A Gecko fix to add insert()/update() but still keep add()/put().
2. A Gaia fix to change apps to use insert()/update().
3. A Gecko fix to remove add()/put().

And of course, I'd like to hear from Jonas and Bent's opinions first about if this change makes sense.
I don't feel strongly. However generally developers prefer short names. And alining with the IndexedDB standard seems nice.

But of course .add() should not work if an object with the provided id already exists.
Flags: needinfo?(jonas)
(In reply to comment #6)
> But of course .add() should not work if an object with the provided id already
> exists.

I think this is basically a separate issue which needs to be filed and fixed no matter what naming we end up with here.

I honestly don't see a good case for changing these names here, I don't think either of the two alternatives are clear winners in terms of clarity.
Assignee: nobody → amarchesini
I agree with comment 7.
Flags: needinfo?(bent.mozilla)
Tentatively close this one as WONTFIX, which is not worth renaming the names.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: