[google-appengine] Re: synthentic keys - performance implications?

2009-08-25 Thread Jeff Enderwick
For posterity, one such gotcha is a case where Model instances work fine, but Expando instances can loose their additive attributes coming back out of the datastore. Switched to factory @staticmethod, and all is good now... On Tue, Aug 25, 2009 at 6:32 AM, Nick Johnson (Google) wrote: > On Mon, A

[google-appengine] Re: synthentic keys - performance implications?

2009-08-25 Thread Nick Johnson (Google)
On Mon, Aug 24, 2009 at 6:44 PM, Jeff Enderwick wrote: > > thanks - I got bit by those __init__ nuances over the weekend. I ended > up passing an optional flag to the __init__ to say "this is really a > new() vs a datastore reconstitution". I del the optional flag from > kwargs before calling the

[google-appengine] Re: synthentic keys - performance implications?

2009-08-24 Thread Jeff Enderwick
thanks - I got bit by those __init__ nuances over the weekend. I ended up passing an optional flag to the __init__ to say "this is really a new() vs a datastore reconstitution". I del the optional flag from kwargs before calling the super __init__. In the datastore reconstitution case, I do nothin

[google-appengine] Re: synthentic keys - performance implications?

2009-08-24 Thread Sylvain
do not forget to add a prefix to the key_name (ie : 'k:',...) Else if your key_name starts with a number it will raise an error On 24 août, 12:56, "Nick Johnson (Google)" wrote: > Hi Jeff, > > On Sat, Aug 22, 2009 at 7:24 PM, Jeff Enderwick > wrote: > > > > > > > > > > > Currently, one must put

[google-appengine] Re: synthentic keys - performance implications?

2009-08-24 Thread Nick Johnson (Google)
Hi Jeff, On Sat, Aug 22, 2009 at 7:24 PM, Jeff Enderwick wrote: > > Currently, one must put() in order to have obj.key() be valid. In some > flows, I find my self having to put() object twice for this reason. > > If I make a synthetic key, it appears that I can avoid this: > > class Joker(db.Mode