Fragmented models are the way to do especially if you are going to be doing writes. This will keep the other entities (the ones you are not writing to) from being locked during writes.
I'm not sure if I fully understand what your data is modeling based on what you are describing and what your view is displaying. With a little more detail in explanation I might be able to provide a better answer. That being said, if your only choices were Option 1 and Option 2 I would choose Option 2 without a doubt. Option 1 will actually be a lot more looks ups. Remember, each reference property results in a DB look up when you go to pull it out. Using Option 1 as an example, you will have a total number of looks ups to get the data for SalesVolume and Hours of (totalResults + 1) which could get pretty hairy. Using Option 2 and doing two queries (1 for SalesVolume and 1 for Hours) gets you the same result set. Mike On Sep 11, 10:59 am, GAEfan <[EMAIL PROTECTED]> wrote: > Thanks, Mike. > > I think you are correct, in that I will have to turn my 60 property > model into, maybe 15 4 property models. That is a fragmented way to > carry my data, but at least it will scale, and not fill the query > memory with unused properties. Tailoring the objects to the views is > the proper way to be efficient and scale. > > Yes, I am guilty of designing this relationally. I thought it made it > simple, but the GAE queries are not made to pull properties from an > entity, but the entity as an entire object. So, to pull the email > addresses out from your members, you have to either carry the email > addresses in a separate model, or limit the number per query to the > number of complete entities (all properties included) that will fit > into memory. > > Let this be a lesson to any other new users who think they should just > import their SQL csv into the datastore. > > So, back to the question... This now turns to syntax... My model list > properties by date, so I am wondering if I should use the > ReferenceProperty feature or not. If I want to just pull out all the > sales figures by date, what should I do? > > Option 1) > > class myDate(BaseModel): > Date = db.DateProperty() > > class SalesVolume(BaseModel): > Date = db.ReferenceProperty(myDate, > collection_name='sales_ref') > Sales = db.FloatProperty() > > class Hours(BaseModel): > Date = db.ReferenceProperty(myDate, > collection_name='hours_ref') > Hours = db.FloatProperty() > > class NumberOne(BaseModel): > Date = db.ReferenceProperty(myDate, > collection_name='number1_ref') > NumberOne = db.FloatProperty() > > If I want to just pull out ONLY the SalesVolume and Hours for each > date, what would my query look like? Remember, I do not want the > NumberOne in memory. Can I do it in one query? Do I need to do 2 > separate queries? What purpose does the ReferenceProperty serve? > > I think if I do a myDate.all().filter(...) , I still will get every > Related property put into the query. > > Should I forget about the reference, and just do: > > Option 2) > > class SalesVolume(BaseModel): > Date = db.DateProperty() > Sales = db.FloatProperty() > > class Hours(BaseModel): > Date = db.DateProperty() > Hours = db.FloatProperty() > > class Number(BaseModel): > Date = db.DateProperty() > Number = db.FloatProperty() > > Here, I end up with 3 separate models, and would certainly need 3 > separate queries. > > Any help on best practice here is greatly appreciated. > > Thank you. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
