I got it. Thanks a lot! =) Em quarta-feira, 28 de janeiro de 2015 05:36:16 UTC-2, Mihail Russu escreveu: > > *>> - I really forgot the point of multiple instances, lol.* > When you get a lot of traffic and/or depending on how much resources your > app needs, GAE will start launching new instances (virtual machines) at > some point to make sure your project runs under any load. The new instances > could even be located in different geographic locations so obviously they > won't be sharing same RAM so your "ALL_RESTAURANTS = []" (which is only > saved in local machine's RAM) will be different on each instance and you > don't really know which instance will handle your next request so some > requests could be returning different results than others. This is one > reason directly related to GAE but as you mentioned yourself it's also just > not a good programming practice. > > *>> - Why should i use ndb instead db?* > ndb is newer, faster, better version of db. It also does some nice things > like caching for you which makes things cheaper in many cases (gets). The > underlying datastore is identical though... See the cheatsheet for more > differences and how to migrate from db in ndb if you decide to do so. > <https://docs.google.com/document/d/1AefylbadN456_Z7BZOpZEXDq8cR8LYu7QgI7bt5V0Iw/edit?ndplr=1&pli=1> > > *>> - Actually this questions of save orders and products leaves me with > insomnia, because i need to decide how to construct the appropriate data > structure. I raised the hypothesized of create a "code" for each product, > because i need to send a product list and orders to a .js client via > channel API. In first attempt i tried to store a dictionary, but did not > work so a converted in to a string. However, i guess i got your > suggestion, if i have different data models i cand bind them from the key > (email).* > Don't forget that an entity cannot be larger than 1MB so you could > potentially at some point have so many orders/products for a particular > "Establishment" / "Restaurant" that they wouldn't fit a single > establishment. + the larger the entity is the more time it will take to get > it form datastore and to parse the string (or the dictionary) into the > object you need. > > For your example you could have something like this below the "class > Establishment(db.Model)" definition: > > class Order(db.Model): > date = db.DateProperty() > people = db.IntegerProperty() > cost = db.FloatProperty() > products = db.KeyProperty(kind=Product, repeated=True) #could be useful > if each order contains a list of products used for that order > #establishment = db.KeyProperty(kind=Establishment) #might or might not > be necessary > ... > > class Product(db.Model): > name = db.StringProperty() > cost = db.FloatProperty() > available = db.BooleanProperty() > #establishment = db.KeyProperty(kind=Establishment) #might or might not > be necessary > ... > > To "bind" them all you could either have an "establishment" property in > both Order/Product classes and have it point to a particular establishment > or you could use the establishment key as the parent of the Order/Product > entity. You would need to understand the difference first and decide for > yourself which would better work for you. > > > *>> - you said: "You might not need any (most) of the indexes", can you > please show me an example?* > I don't really know if that's also the case with db but in ndb all your > model properties are indexed by default which means you can query on any of > them (i.e. show restaurants where the name == 'xxx' or orders == 'yyy'). > Most of the time you don't need that and it also makes writes a lot more > expensive. In your Establishment model you may or may not need to index > name/email properties but the orders / products properties sound like they > might change a lot and don't need to be indexed (this is just a guess) so > you would define them as: > orders = db.StringProperty(indexed=False) > products = db.StringProperty(indexed=False) > > > On Tuesday, January 27, 2015 at 7:52:52 PM UTC+2, Saturnino Mateus wrote: >> >> Thanks for the answer. >> Basing in what you said, i have a few questions: >> - I really forgot the point of multiple instances, lol. >> - Why should i use ndb instead db? >> - Actually this questions of save orders and products leaves me with >> insomnia, because i need to decide how to construct the appropriate data >> structure. I raised the hypothesized of create a "code" for each >> product, because i need to send a product list and orders to a .js client >> via channel API. In first attempt i tried to store a dictionary, but did >> not work so a converted in to a string. However, i guess i got your >> suggestion, if i have different data models i cand bind them from the key >> (email). >> - you said: "You might not need any (most) of the indexes", can you >> please show me an example? >> >> Best Regards! >> >> Em terça-feira, 27 de janeiro de 2015 13:57:19 UTC-2, Mihail Russu >> escreveu: >>> >>> Yes, your ALL_RESTAURANTS list will not always contain the full list of >>> Restaurants for many reasons, including the ones you provided. >>> >>> Also, there are some more things I noticed in your code at a glance: >>> >>> - Your project will run on multiple instances meaning each instance >>> will have its own copy of ALL_RESTAURANTS so you will likely not be getting >>> any consistent results of what's in the ALL_RESTAURANTS list. >>> >>> - You should be using NDB instead of older DB >>> >>> - It *might *be a good idea to have "orders" and "products" properties >>> as separate data models rather than strings. >>> >>> - Since one email seem to only have one restaurant you could use the >>> email address as the "id" of the restaurant, this would let you do free >>> "get by id" rather than expensive queries queries. >>> >>> - You might not need any (most) of the indexes (i.e. you need to >>> specify indexed=False next to each property that you do not want to be >>> indexed) >>> >>> Thanks, >>> Mihail. >>> >>> >>> On Tuesday, January 27, 2015 at 1:03:21 PM UTC+2, Saturnino Mateus wrote: >>>> >>>> I'm facing a problem with code organization with GAE, so i'm trying >>>> this solution below. I created a global list wich will contains all >>>> Restaurant objects reference, i know that is not good programming practice >>>> and here i go with my doubt: is there some how i lost every Restaurant >>>> references appended on the list? Like Google server go down and lost? >>>> >>>> ALL_RESTAURANTS = [] >>>> >>>> class Establishment(db.Model): >>>> name = db.StringProperty() >>>> email = db.StringProperty() >>>> orders = db.StringProperty() >>>> products = db.StringProperty() >>>> state = db.StringProperty() >>>> >>>> class Restaurant(object): >>>> def __init__(self,name,email): >>>> self.name = name >>>> self.email = email >>>> >>>> def save(self): >>>> que = db.Query(Establishment) >>>> que.filter('email =',self.email) >>>> results = que.fetch(limit=1) >>>> >>>> if len(results)>0: >>>> logging.info('Already exist a restaurant associated to >>>> this email') >>>> return False >>>> else: >>>> restaurant = Establishment(name=self.name >>>> ,email=self.email,products='empty',orders='empty',state='OFFLINE') >>>> restaurant.put() >>>> logging.info('Restaurant '+self.email+' saved in DB!') >>>> return True >>>> >>>> class TheHandler(webapp2.RequestHandler): >>>> def get(self): >>>> newRestaurant = Restaurant(name='The Pizza',email=' >>>> [email protected]') >>>> newRestaurant.save() >>>> ALL_RESTAURANTS.append(newRestaurant) >>>> >>>> anotherRestaurant = Restaurant(name='The Other Pizza',email=' >>>> [email protected]') >>>> anotherRestaurant.save() >>>> >>>> ALL_RESTAURANTS.append(anotherRestaurant) >>>> Best Regards... >>>> >>>>
-- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/75d0b66e-13b2-4367-8123-c248ab0577ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
