[google-appengine] Re: GQL join question
The average is maybe not the correct description, better is to call it
usage.
On 6 apr, 22:46, Alkis Evlogimenos ('Αλκης Ευλογημένος)
evlogime...@gmail.com wrote:
On Mon, Apr 6, 2009 at 8:53 PM, Marcel Overdijk
marceloverd...@gmail.comwrote:
(1) Now what I want to collect is the average value per month.
E.g
- User1, 1 jan 2009, 1000
- User1, 1 feb 2009, 1100
- User1, 1 mar 2009, 1200
The avarage will be 100
But maybe the user misses registering the meter reading on 1 feb:
- User1, 1 jan 2009, 1000
- User1, 1 mar 2009, 1200
The average will still be 1200
The average is 1200? Or 100?
--
Alkis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: GQL join question
This would mean really a lot of updates. E.g. - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 This would mean craeting an avarage usage of 100 for jan 2009. Now next time the user enters a meter reading is e.g. 1 jan 2010 with value 2300. This would mean in this case createing avaerage use valuues for feb, mar, apr, may, jun, jul, aug, sep, okt, nov and dec 2009. And als updating average usage of all users. In a SQL join this would be less dificult and error prone to implement. I'm wondering if my use case fits the BigTable principles and thus GAE, or that I would be better of with a realtional database. But this would mean I can't use GAE and have to go for another cloud solution like mor.ph On 7 apr, 06:36, GregF g.fawc...@gmail.com wrote: On Apr 7, 6:53 am, Marcel Overdijk marceloverd...@gmail.com wrote: - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 - User1, 1 mar 2009, 1200 The avarage will be 1100 *** But maybe the user misses registering the meter reading on 1 feb: - User1, 1 jan 2009, 1000 - User1, 1 mar 2009, 1200 The average will still be 1100 *** I guess the answer will be to store average values when creating (and updaing existing) meter reading records. But how should this be implemented? *** Corrected. Yes, calculate averages when you update the table. If you don't need to search for particular readings, you might want to store the meter readings in a db.ListProperty(int), with an associated db.ListProperty (int) of timestamps. I need to count various things in my app, so I define a model and helper functions like this: class Counter(db.Model): count=db.IntegerProperty(required=True,default=0) # Increment a counter # NB: These are functions, not class members def _incrementCounter(counterId,amount): counter=Counter.get_by_id(counterId) counter.count+=amount counter.put() def incrementCounter(counterId,amount=1): db.run_in_transaction(_incrementCounter,counterId,amount) I'm sure you can do something similar for your averages. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: GQL join question
Hi Marcel, the SQL join world saves you the hassle of thinking about all of this stuff at write-time, but would not scale beyond a few thousand users. if you implement everything in SQL and then end up with a very busy site, you end up re-implementing all of your data access to work in the BigTable way. one nice thing about BigTable is that when you do a db.put(entities) where entities is an array/list, it sends them away to write in multiple threads. so the access time is not linear with len (entities). sharded counter = awesome Ben On Apr 7, 2:48 am, Marcel Overdijk marceloverd...@gmail.com wrote: This would mean really a lot of updates. E.g. - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 This would mean craeting an avarage usage of 100 for jan 2009. Now next time the user enters a meter reading is e.g. 1 jan 2010 with value 2300. This would mean in this case createing avaerage use valuues for feb, mar, apr, may, jun, jul, aug, sep, okt, nov and dec 2009. And als updating average usage of all users. In a SQL join this would be less dificult and error prone to implement. I'm wondering if my use case fits the BigTable principles and thus GAE, or that I would be better of with a realtional database. But this would mean I can't use GAE and have to go for another cloud solution like mor.ph On 7 apr, 06:36, GregF g.fawc...@gmail.com wrote: On Apr 7, 6:53 am, Marcel Overdijk marceloverd...@gmail.com wrote: - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 - User1, 1 mar 2009, 1200 The avarage will be 1100 *** But maybe the user misses registering the meter reading on 1 feb: - User1, 1 jan 2009, 1000 - User1, 1 mar 2009, 1200 The average will still be 1100 *** I guess the answer will be to store average values when creating (and updaing existing) meter reading records. But how should this be implemented? *** Corrected. Yes, calculate averages when you update the table. If you don't need to search for particular readings, you might want to store the meter readings in a db.ListProperty(int), with an associated db.ListProperty (int) of timestamps. I need to count various things in my app, so I define a model and helper functions like this: class Counter(db.Model): count=db.IntegerProperty(required=True,default=0) # Increment a counter # NB: These are functions, not class members def _incrementCounter(counterId,amount): counter=Counter.get_by_id(counterId) counter.count+=amount counter.put() def incrementCounter(counterId,amount=1): db.run_in_transaction(_incrementCounter,counterId,amount) I'm sure you can do something similar for your averages. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: GQL join question
On Mon, Apr 6, 2009 at 8:53 PM, Marcel Overdijk marceloverd...@gmail.comwrote: (1) Now what I want to collect is the average value per month. E.g - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 - User1, 1 mar 2009, 1200 The avarage will be 100 But maybe the user misses registering the meter reading on 1 feb: - User1, 1 jan 2009, 1000 - User1, 1 mar 2009, 1200 The average will still be 1200 The average is 1200? Or 100? -- Alkis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: GQL join question
On Apr 7, 6:53 am, Marcel Overdijk marceloverd...@gmail.com wrote: - User1, 1 jan 2009, 1000 - User1, 1 feb 2009, 1100 - User1, 1 mar 2009, 1200 The avarage will be 1100 *** But maybe the user misses registering the meter reading on 1 feb: - User1, 1 jan 2009, 1000 - User1, 1 mar 2009, 1200 The average will still be 1100 *** I guess the answer will be to store average values when creating (and updaing existing) meter reading records. But how should this be implemented? *** Corrected. Yes, calculate averages when you update the table. If you don't need to search for particular readings, you might want to store the meter readings in a db.ListProperty(int), with an associated db.ListProperty (int) of timestamps. I need to count various things in my app, so I define a model and helper functions like this: class Counter(db.Model): count=db.IntegerProperty(required=True,default=0) # Increment a counter # NB: These are functions, not class members def _incrementCounter(counterId,amount): counter=Counter.get_by_id(counterId) counter.count+=amount counter.put() def incrementCounter(counterId,amount=1): db.run_in_transaction(_incrementCounter,counterId,amount) I'm sure you can do something similar for your averages. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
