Server go down

[Saturnino Mateus]

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='te...@example.com')

        newRestaurant.save()

        ALL_RESTAURANTS.append(newRestaurant)

        anotherRestaurant = Restaurant(name='The Other Pizza',email='te...@example.com')

        anotherRestaurant.save()

        ALL_RESTAURANTS.append(anotherRestaurant)

Best Regards...

[Mihail Russu]

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.

[Saturnino Mateus]

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! 

[Mihail Russu]

>> - 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.

>> - 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)

[Saturnino Mateus]

I got it. Thanks a lot! =)