Thanks for the blog entries!
Regards,
- Yagiz -
class Library(db.Model):
name = db.StringProperty()
address = db.StringProperty()
def books(self):
return (x.book for x in self.book_set)
class Book(db.Model):
title = db.StringProperty()
def libraries(self):
return (x.library for x in self.librarybook_set)
class LibraryBook(db.Model):
library = db.ReferenceProperty(Library)
book = db.ReferenceProperty(Book)
Then you can CRUD the LibraryBook and store quantities there, etc.
Regards,
Jeremey.
Habits take time to change. We, as an industry, have been focusing on
speed and size just about forever. It's only when you pull back from
the micro world and focus on what we are attempting to achieve that
you realise that you can achieve real world usability doing things
that seem counter-intuitive on first pass.
Intuitive, of course, is another way of saying familiar. =)
> James
--
Brett Morgan http://brett.morgan.googlepages.com/
Hi,
Here is my modification of James example.py.
I've removed cleaned it up a bit for clarity (removing the Libraries
and Books datamodel).
(this is just the example.py replacement)
http://cluebin.appspot.com/pasted/25
Regards,
/Johan
--
Johan Carlsson
Colliberty Easy Publisher
http://www.easypublisher.com
Yes, all of the above concerns are valid. Yes, denormalisation hurts,
both on disk space, and on correctness.
The reason we are doing this is to achieve scale. At scale you wind up
doing a bunch of things that seem wrong, but that are required by the
numbers we are running. Go watch the EBay talks. Or read the posts
about how many database instances FaceBook is running.
The simple truth is, what we learned about in uni was great for the
business automation apps of small to medium enterprise applications,
where the load was predictable, and there was money enough to buy the
server required to handle the load of 50 people doing data entry into
an accounts or business planning and control app.
On the web, we are in a different world. If you get successful, you'll
get slashdotted. Well, these days it's probably more correct to call
it reddited. Or boing boinged. And suddenly you have to go from 4
servers to fourty, to four hundred, to four thousand. Read up the
story about the iLike guys. They wrote an app that went viral on FB.
And they melted. Needed servers. Yesterday.
What GAE gives you is the ability to handle this, easily. All the
things that GAE makes you do is done with this end game in mind. You
have to write your code such that it can run on 400 app servers spread
across the globe, on google's infrastructure. You have to deal with
the fact that the transaction engine is distributed. You have to deal
with the fact that queries are slow, and you should really be
publishing entities that match one to one with your popular pages. And
that you need to hide your updates using ajax. It's better to give the
user a progress bar than a white screen of death, anyways.
If you aren't interested in serving millions of customers, then this
is likely overkill for you. But if you are, then you have to go
through this world view change. And yes it hurts. I'm not going to say
it's easy. It hurt me when I had to go through it back in 2000. It
actually took me about four attempts (aka, webapps that melted
underload) before i got it. But, once you make the leap, and
understand that we are breaking rules for a reason, then you'll
understand where and when to do it. Every choice has costs and
benefits. Understanding when GAE makes sense is part of this journey
of discovery.
And if any of the above doesn't make sense, feel free to come back
with more questions. =)
Yes, splitting things so that you have a primary data source, and the
published cache entities makes sense. It's a strategy i've suggested
several times in various situations.
As for background tasks, you could always star my issue:
http://code.google.com/p/googleappengine/issues/detail?id=6
> It seems to me that a large part of this could be automated though. I
> really like how the datastore indices are automatically generated in
> the index.yaml file without any action on the developers part. I'm new
> to python and GAE but how feasible would it be to write a plugin that
> automatically does this sort of "caching"?
Probably. I haven't thought that far. =)
--
Brett Morgan http://brett.morgan.googlepages.com/