> <snip> > > The backend data store, while it has a vaguely SQLish query language is an > > object database not a relational database, i.e. more like ZODB than MySQL. > > It uses similar concepts to django's data api but isn't the same. It > should > > be possible to write something simple to replace it, but given that you > > only need to migrate away from Google when your data or page hits get > > large, you need to replace it with something scalable. > > I have a bet with a coworker that someone will implement the api, in a > way that makes migration away from Google easy, within a month. > (actually, the bet is just that there will be a project with this > goal). The reason I mention it here, is that he had the same comments > as you regarding this. My thinking is that (if past experiences can be > used as a yardstick) the python community will see this deficiency and > work to correct it. As a result of that thinking, I am fairly certain > that this concern is not a big concern. The authentication thing, > thats a bit different.
The best would be if the google datastore backend would be available from sqlalchemy or sqlobject. I understand that the google datastore is not a relational database but that just means that the full power of sqlalchemy or sqlobject would not be available for this backend only a limited subset. I think this should be doable especially because GQL is very similar to SQL looks like it's really a proper subset. -- http://mail.python.org/mailman/listinfo/python-list
