Skip to content
This repository has been archived by the owner on Dec 25, 2023. It is now read-only.

Projected entity loses projection after pickling #215

Closed
GoogleCodeExporter opened this issue Jun 10, 2015 · 7 comments
Closed

Projected entity loses projection after pickling #215

GoogleCodeExporter opened this issue Jun 10, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?

import cPickle
from google.appengine.ext import ndb

class TestModel(ndb.Model):
  foo = ndb.StringProperty()

model1 = TestModel(foo='bar', projection=('foo',))
model2 = cPickle.loads(cPickle.dumps(model1, -1))
print model1 == model2, model2._projection


What is the expected output?  True ('foo',)
What do you see instead?  False ()


What version of the product are you using? On what operating system?
1.7.3 on Mac OS X


Please provide any additional information below.

This is mildly problematic when putting projected entities in memcache, since 
when retrieved they no longer have the projection's safety constraints (no 
access to unprojected properties, no putting, etc.).

ndb.Model._from_pb appears to have some code to restore a projection by looking 
for meaning == entity_pb.Property.INDEX_VALUE, however _to_pb / 
ndb.Property._serialize don't set a meaning.  I assume this is because other 
users of _to_pb require that such a meaning not be written, so perhaps this 
calls for yet another flag on _to_pb?

Original issue reported on code.google.com by pi...@knowlabs.com on 11 Oct 2012 at 2:04

@GoogleCodeExporter
Copy link
Author

Interesting. I don't know how much priority to give this, but you're right this 
is unexpected behavior.

As a word-around, I'd recommend that you store your data in a form that isn't 
so easily confused, e.g. as a tuple or a dict (you could even use _to_dict()).

Also please everybody note that you've hit undefined behavior, so don't start 
writing code that depends on this behavior!

Original comment by guido@google.com on 11 Oct 2012 at 3:39

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Would it be acceptable to consider a partial entity as "incomplete" and make 
the dumps() call in the example above raise BadRequestError?

Please review http://codereview.appspot.com/6842077

Original comment by gvanrossum@gmail.com on 21 Nov 2012 at 12:20

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

That would be worse than the current behavior from my point of view, since it 
would make me jump through hoops to cache projected models.

Original comment by pi...@knowlabs.com on 21 Nov 2012 at 1:51

@GoogleCodeExporter
Copy link
Author

Fair enough. Do you feel comfortable trying to make a patch yourself? I guess 
it should change _to_pb() to generate the necessary meaning values.

Original comment by guido@google.com on 21 Nov 2012 at 2:38

@GoogleCodeExporter
Copy link
Author

Original comment by guido@google.com on 6 Dec 2012 at 11:10

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Original comment by arful...@google.com on 16 Mar 2013 at 6:57

@GoogleCodeExporter
Copy link
Author

Original comment by arful...@google.com on 12 Jun 2013 at 11:44

  • Changed state: Fixed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant