iPhone app with Goole App Engine

Question

I've prototyped an iPhone app that uses (internally) sqLite as its data base. The intent was to ultimately have it communicate with a server via PHP, which would use mySQL as the backend database.

I just discovered Google App Engine, however, but know very little about it. I think it'd be nice to use the Python interface to write to the datastore - but I know very little about GQL's capability. I've basically written all the working database code using mySQL, testing internally on the iPhone with sqLite. Will GQL offer the same functionality that SQL can? I read on the site that it doesn't support join queries. Also is it truly relational?

Basically I guess my question is can an app that typically uses SQL backend work just as well with Google's App Engine, with GQL?

I hope that's clear... any guidance is great.

Answer 1

I think this article should help you.

Summary: Cloud computing and software development for handheld devices are two very hot technologies that are increasingly being combined to create hybrid solutions. With this article, learn how to connect Google App Engine, Google's cloud computing offering, with the iPhone, Apple's mobile platform. You'll also see how to use the open source library, TouchEngine, to dynamically control application data on the iPhone by connecting to the App Engine cloud and caching that data for offline use.

Answer 2

That's a pretty generic question :)

Short answer: yes. It's going to involve some rethinking of your data model, but yes, changes are you can support it with the GAE Datastore API.

When you create your Python models (think of these as tables), you can certainly define references to other models (so now we have a foreign key). When you select this model, you'll get back the referencing models (pretty much like a join).

It'll most likely work, but it's not a drop in replacement for a mySQL server.

Answer 3

True, Google App Engine is a very cool product, but the datastore is a different beast than a regular mySQL database. That's not to say that what you need can't be done with the GAE datastore; however it may take some reworking on your end.

The most prominent different that you notice right off the start is that GAE uses an object-relational mapping for its data storage scheme. Essentially object graphs are persisted in the database, maintaining there attributes and relationships to other objects. In many cases ORM (object relational mappings) map fairly well on top of a relational database (this is how Hibernate works). The mapping is not perfect though and you will find that you need to make alterations to persist your data. Also, GAE has some unique contraints that complicate things a bit. One contraint that bothers me a lot is not being able to query for attribute paths: e.g. "select ... where dog.owner.name = 'bob' ". It is these rules that force you to read and understand how GAE data store works before you jump in.

I think GAE could work well in your situation. It just may take some time to understand ORM persistence in general, and GAE datastore in specifics.

Answer 4

GQL offers almost no functionality at all; it's only used for SELECT queries, and it only exists to make writing SELECT queries easier for SQL programmers. Behind the scenes, it converts your queries to db.Query objects.

The App Engine datastore isn't a relational database at all. You can do some stuff that looks relational, but my advice for anyone coming from an SQL background is to avoid GQL at all costs to avoid the trap of thinking the datastore is anything at all like an RDBMS, and to forget everything you know about database design. Specifically, if you're normalizing anything, you'll soon wish you hadn't.