ndb.IntegerProperty doesn't work in generated Android libraries about endpoints-proto-datastore HOT 8 CLOSED

Thanks for filing this.

This is a bug that trickles down to protorpc.

Since JSON (the spec) relies on Javascript, our fields with format equal to int64 must be represented with the JSON type string, rather than the JSON type integer, which can be used with format equal to int32 (for precision reasons).

I'll update with either a short-term hack to deal with protorpc or a short term hack to make 'id' use int32.

_{NOTE: THIS POST WAS EDITED AFTER BEING MIGRATED.}

_{Code Hosting Comment Metadata:
author.htmlLink=https://code.google.com/u/[email protected]/
author.name=[email protected]
id=1
published=2013-02-28T01:12:09.000Z
updates.status=Accepted}

from endpoints-proto-datastore.

So currently I can only recommend these "hacks" and say we are working on the fix in protorpc:

1. Override "id" in a similar fashion that "order" is overridden in the custom alias properties sample. For example:

class MyModel(EndpointsModel):
  _message_fields_schema = ('id', ...)

  # ...

  @EndpointsAliasProperty(setter=EndpointsModel.IdSet,
                          property_type=messages.IntegerField,
                          variant=messages.Variant.INT32)
  def id(self):
    return super(MyModel, self).id

2. Patch "id" directly after your class definition (making sure to do this before ProtoModel is ever called). For example:

class MyModel(EndpointsModel):
  _message_fields_schema = ('id', ...)

  # ...
MyModel.id._variant = messages.Variant.INT32

3. Patch the source method "id" in EndpointsModel to add the variant as is done in 1) above.

_{NOTE: THIS POST WAS EDITED AFTER BEING MIGRATED.}

_{Code Hosting Comment Metadata:
author.htmlLink=https://code.google.com/u/[email protected]/
author.name=[email protected]
id=2
published=2013-02-28T17:57:03.000Z
updates.cc=[
  [email protected],
  [email protected],
]
updates.owner=[email protected]}

from endpoints-proto-datastore.

With this workaround, there still seems to be an issue for integers largers than int32max, but less than int64max, as you can set them in the datastore, but then they crash the client because they can't be parsed in the generated code.

It seems like we'd either want support for 64-bit ints that work all the way through the system, or we should prevent ints larger than int32max from being written in the first place.

Any updates on the "proper" fix for this particular issue? Is this library still being actively maintained?

from endpoints-proto-datastore.

Rich, though you can set them in the database, you can't actually set anything above int32max on a ProtoRPC field can you?

Also, I'm not sure this is relevant any more. This was opened because int64 is a special type that uses the JSON string type to represent data while int32 uses the integer JSON type. Previously, the Python ProtoRPC library did not adhere to this but that was fixed when protojson.py was added.

Maybe I'm missing something? Maybe @kdeus has some more insights?

from endpoints-proto-datastore.

ProtoRPC was fixed to support int64 as a string a while back. As far as I know, int64 should work on that side. But I couldn't say for sure if endpoints-proto-datastore is doing something unusual that might cause problems.

from endpoints-proto-datastore.

@kdeus The library itself doesn't do anything unless the code above is used. Maybe @ubragg can weigh in with some comments about his use/his findings.

from endpoints-proto-datastore.

Well, I went ahead and replaced all of my instances of
EndpointsVariantIntegerProperty with ndb.IntegerProperty, re-built my
Android client libraries, reset any local data I had stored on the device
from the old libraries, and now everything works. So the good news is that
the issue I was having is in fact now moot, as there is no longer a need
for the EndpointsVariantIntegerProperty workaround.

I suspect the issues I was having with the workaround are no longer
relevant, since the workaround is no longer necessary. In the mean time, I
think this issue can be closed, although it might be worth removing the
workaround code from the endpoints-proto-datastore library at some point.

Thanks for the tips guys!

On Mon, Nov 18, 2013 at 11:22 AM, Danny Hermes [email protected]:

@kdeus https://github.com/kdeus The library itself doesn't do anything
unless the code above is used. Maybe @ubragg https://github.com/ubraggcan weigh in with some comments about his use/his findings.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-28728775
.

from endpoints-proto-datastore.

I gotcha! So there is still in issue with the way int32 and other non-default types are handled but in general this isn't an issue.

from endpoints-proto-datastore.