limeuser / appengine-ndb-experiment

Automatically exported from code.google.com/p/appengine-ndb-experiment
Other
0 stars 0 forks source link

Projected entity loses projection after pickling #215

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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