Actually, webpy requires even less typing than webapp, which seems to be more explicit. But the most important thing is “portability”.
Only the database api changes (because of bigtable’s datastore), but all the rest can be kept unchanged.

So if you want a very simple solution (even simpler than webapp) and you want portability, give webpy a shot. You will like it.

You can do things like, “select …. height>70 AND height<90″ the documentation says you can only use more then one on one property, eg height.

BUT you cannot use on more than one property in the same query.
for example “select … height>70 AND weight>50″ because now you are doing 2 properties height and weight.

LASTLY, you can use = for everything else.
eg “Select …. height=70 AND weight=70 AND sex=”male” AND birthday > 1977″ is valid because only 1 greater than query has been used.

If you think this is limiting, I would doubt it. Google uses this DB for nearly everything so if they can so can you. If it does become a problem you may have to preprocess some data or think of some smart ways to handle the data.

Man cannot wait for invite. Have built one app, nearly on to my next. I am so impatient that I have installed Django mod_python and sqlite on my server because I have been enjoying python a lot (but Django seems very complicated when compared with GAE).

Cheers, John.

SELECT * FROM Person WHERE last_name = “Smith” AND height < 72 ORDER BY height DESC

That query looks strangely familiar to the one in the that they said was not valid in the “Restrictions on queries” section. It said “A query may only use inequality filters (<, =, and >) on one property across all of its filters.”

So, would someone smarter than me please visit this link and make sense of this page? It appears from the examples that it works the way you think it would, then they throw in this restrictions section which seems to contradict everything they have just said… help!

http://code.google.com/appengine/docs/datastore/queriesandindexes.html

SELECT * FROM Person WHERE birth_year >= :min_year AND height >= :min_height

It also said that “Inequality Filters Are Allowed On One Property Only”, so you cant put a filter on birth_year and height if I am understanding correctly. Is there some sort of another way to get at this recordset? Do they offer subfilters of filters or something?

It also says that “The datastore does not have support for the not-equal (!=) operator for filters.” Which means I could not pull from the DB all records of people NOT from california. Unless there is some other way to get at this recordset.

I sure hope I am wrong here and there is some way to do this stuff because I cant think of an application I’ve written that didnt have need to filter on multiple fields at some point.

Unless I misunderstand what you’re trying to do, you should be able to use filters to do that.

You will have to change the way you do things to suit how Bigtable works, however. Since disk space is essentially free these days, you should try and precompute as much as possible at write-time to minimize the cost of reads. And forget about normalization and joins (from what I’ve read, Bigtable does support joins but this hasn’t — yet? — been exposed in Google App Engine):)

The only other thing I can think of is that I am simply misreading the limitations and there must be another way to deal with the issue.

Have you actually read the restrictions the datastore API has? Am I the only developer that thinks these are HIGHLY prohibitive. In fact it makes GAE largely unusable for me.

No way to pull something from a DB like “everyone who is over 23 yeas old, with blue eyes”?!?!? how do you not support that??? No way to query “everyone who is not from california”?!?! how do you not support that??? Only able to pull 1000 records max, are you joking me??

Am I missing something??? http://code.google.com/appengine/docs/datastore/queriesandindexes.html (see the “Restictions” section to be blown away)

I’ve been considering the portability issue and I hear you on Django being more portable in the here and now. It’s also true that the webapp framework is proprietary. Google have, however, open sourced it and they have released the Development Web Server as open source also. This is really all anyone needs to create webapp-compatible hosting packages that are not tied to Google. In the coming days, I am confident we will see other implementations of GAE that make it easier to move your app off of Google’s domain if you should desire.

So I don’t really see GAE/webapp as lock-in but rather as an emerging new de-facto standard.

Building something with webapp means it’s stuck with Google, on a platform for which they have yet to release the pricing for. Building something using Django means I have more choice. It’s not truly portable yet but changes would likely be relatively simple replacement affairs mainly in the models.

Having said all that, I am having to fight against Django to make it work at the moment so whether it’s worth the extra effort time will tell.