db's collection.find should treat ids as strings not numbers about ember-cli-mirage HOT 11 CLOSED

Thanks for the background, and this totally makes sense to me.

What if someone's API sends up json with an id field as an int? Would they not be able to mock our their server using mirage?

from ember-cli-mirage.

Good question. I suppose another option is to simply not transform IDs at all, and put the onus on users to be consistent.

from ember-cli-mirage.

I think the default should be, coerce everything to string, and have a config option that disables coercion.

from ember-cli-mirage.

although, looking at all our rails apps, they definitely serialize ids as ints. I'd imagine this would be the default for most frameworks?

maybe we should default coerce to ints, but have option for coerce to strings, or disable coercion completely.

I basically don't want people to have to do schema.user.find(+id) or schema.user.find('' + id) all over the place.

from ember-cli-mirage.

@samselikoff an option seems OK to me.

from ember-cli-mirage.

I think conceptual problem here is that when a find operation occurs in a back-end framework, the framework is aware of the stored data type of the ID, and can coerce the incoming string query param value accordingly. That coercion may even vary from model to model. But mirage has no such understanding of the underlying storage type today and so cannot intelligently coerce.

IMO, coercing IDs to strings in all cases would be the most robust solution. Developers who want numeric IDs in their serialized responses can customize the response (eventually through a serializer).

from ember-cli-mirage.

Makes sense. Seems like serializers are the answer, and when those land
mirage can do whatever it wants internally (coerce to string). Thanks for
input!
On Fri, May 15, 2015 at 9:17 AM Luke Melia [email protected] wrote:

I think conceptual problem here is that when a find operation occurs in a
back-end framework, the framework is aware of the stored data type of the
ID, and can coerce the incoming string query param value accordingly. That
coercion may even vary from model to model. But mirage has no such
understanding of the underlying storage type today and so cannot
intelligently coerce.

IMO, coercing IDs to strings in all cases would be the most robust
solution. Developers who want numeric IDs in their serialized responses can
customize the response (eventually through a serializer).

—
Reply to this email directly or view it on GitHub
#67 (comment)
.

from ember-cli-mirage.

I believe I'm running into this too. What's the best way for us string-id'd folks to proceed? Is there a work around (beyond just pulling all records from DB and doing the filter myself which I guess I could do)?

Even with the long form I can't coerce to string:

this.get('/activities/:id', function(db, request) {
  const id = String(request.params.id);

  return {
    activity: db.activities.find(id)
  };
});

from ember-cli-mirage.

BTW, I also wonder if the shorthand should be a bit more robust for singular find operations because when it search for a numeric id and doesn't find it returns undefined and ember-data doesn't handle this gracefully. See below:

Obviously if I went with the long form I could handle this quite easily myself but I'm a sucker for the short form. :)

from ember-cli-mirage.

Yah I agree with your points. I'd say for now, can you just use int ids? Ultimately how the id is stored in mirage's db isn't super important, it's more how it comes across the wire. Right now it could be as int, with serializers it will be whatever you want. But if you use int right now, you can use shorthands without too much work.

You're correct in the fail case. What should it be, a 404?

from ember-cli-mirage.

For the data model I'm referring to here I guess I can do that, many of my other models are non-numeric but I'm guessing in these cases that Mirage will not attempt to coerce it to integer, right? Sorry just getting started in mirage so I'll know the answer to this soon. In any event, I think you'll find a lot more people with non-numeric id's when their backend store is a nosql database (it has a tendency to exert this influence on records unlike SQL which the golden rule was always use integer).

WRT to handling of the "undefined" condition, I think a 404 makes sense.

from ember-cli-mirage.