Actually, I believe someone already wrote one and submitted it to the
google code site. I just already had a working solution so didn't
bother implementing it. I don't believe it includes all the features
you mention, but would be a good starting point.
On Oct 28, 10:46 am, Andy Freeman <[EMAIL PROTECTED]> wrote:
> Sounds reasonable.
>
> Is it worth writing a JsonProperty analogous to the PickleProperty
> that I posted previously, possibly combined with the db.Model
> extension that I posted to provide additional db.ReferenceProperty
> features.?
>
> My PickleProperty looks like python data as far as my application is
> concerned but is automatically pickled and unpickled to/from the
> datastore, where it lives as a blob. (db.Key s pickle/unpickle just
> fine.) In other words, data = PickleProperty(default={}) defines a
> property named data that the application can treat as a dict. (Yes,
> PickleProperty copies so each property gets its own dict.) When the
> containing db.Model instance is written to the datastore, the data, a
> dict in this case, is pickled and stored as a blob. When a containing
> db.Model instance is read from the datastore, the blob is unpicked and
> the dict recreated for use by the application. (Pickle/unpickle works
> with a wide variety of data types, including db.Key s, preserves any
> structure sharing and circular references, and even tries to do
> something reasonable with top-level functions.)
>
> I also extended db.Model so there's a db.Key access property for every
> db.ReferenceProperty. For example, when a db.Model instance defines
> identity = db.ReferenceProperty(Identity), my extension also defines
> identity_tag which can be used to read/write the corresponding tag
> without causing a datastore fetch.
>
> I mention PickleProperty and that extension because JsonProperty might
> combine features of both. Like PickleProperty, data = JsonProperty()
> would define a property that is interpreted as python data that is
> read/written into the datastore as json. However, there could also be
> a db.Model extension that defines a property, data_json in this case,
> which would allow the application to access the data as json, so it
> can be sent to/received from the client directly.
>
> On Oct 28, 5:46 am, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > json takes up less space, and also is a bit more portable. Some of the
> > stuff I'm storing it could make sense to pull the json and have it
> > read by javascript, bypassing parsing it with python altogether.
>
> > On Oct 28, 2:28 am, Andy Freeman <[EMAIL PROTECTED]> wrote:
>
> > > Why simplejson instead of pickle?
>
> > > On Oct 27, 10:26 am, "[EMAIL PROTECTED]"
>
> > > <[EMAIL PROTECTED]> wrote:
> > > > The JSON bit was primarily to work around the 1000 item result set
> > > > limit. Since simplejson already exists on appengine, was just easier
> > > > for me to use json to store those data sets that grow beyond 1000
> > > > entities and the convert them to dictionaries to parse.
>
> > > > On Oct 27, 10:40 am, "Paul Kinlan" <[EMAIL PROTECTED]> wrote:
>
> > > > > Hi,
>
> > > > > JSON might work, but it is probably overkill. I was planning on
> > > > > maintaining
> > > > > an inverted index like structure and do some simple set based
> > > > > operations on
> > > > > the data, a ListProperty would have been ideal as AFAIK the data has
> > > > > its
> > > > > order maintained in the list and searching the list would have been
> > > > > quite
> > > > > efficient.
>
> > > > > The 1000 item result set is quite limiting too.
>
> > > > > Paul.
>
> > > > > 2008/10/27 [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>
> > > > > > My workaround for a case like this, as suggested by another member
> > > > > > of
> > > > > > this group, was TextProperty with JSON encoded data.
>
> > > > > > On Oct 27, 10:25 am, "Paul Kinlan" <[EMAIL PROTECTED]> wrote:
> > > > > > > Hi,
>
> > > > > > > Thanks for the information. It is good to know. For what I need
> > > > > > > I
> > > > > > > potentially need more than 5000 items so I will probably have to
> > > > > > > think
> > > > > > of
> > > > > > > another way of doing it.
>
> > > > > > > Cheers and Thanks,
> > > > > > > Paul
>
> > > > > > > 2008/10/27 Waldemar Kornewald <[EMAIL PROTECTED]>
>
> > > > > > > > Hi Paul,
>
> > > > > > > > On Oct 26, 9:49 pm, "Paul Kinlan" <[EMAIL PROTECTED]> wrote:
> > > > > > > > > Is the limit to the number of items in a ListProperty 1000?
> > > > > > > > > I ask
> > > > > > > > because
> > > > > > > > > the limit to the number of results in a Query is 1000 and if
> > > > > > > > > the data
> > > > > > in
> > > > > > > > the
> > > > > > > > > list is stored as seperate entities in the index I am
> > > > > > > > > assuming that
> > > > > > this
> > > > > > > > > means that the limit is 1000 as per the query guidelines.
>
> > > > > > > > The limit is 5000 index entries per entity. So, if you have a
> > > > > > > > StringProperty and a ListProperty you can put 4999 items into
> > > > > > > > the
> > > > > > > > list. The problem just seems to be that put() consumes *lots* of
> > > > > > > > mcycles if your entity needs many index entries. I don't know if
> > > > > > > > that'll change and how much we'll get charged for it.
>
> > > > > > > > Bye,
> > > > > > > > Waldemar Kornewald- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
