Could Drizzle be db backbone for iPhone Application?

wade wrote:
> New question #60680 on Drizzle:
> https://answers.launchpad.net/drizzle/+question/60680
>
> just curious.
> thanks
>

Yes. Except none of us have bothered compiling/porting to iPhone yet. :)

Monty

Hi wade

On 12/02/2009, at 7:35 AM, wade wrote:
> New question #60680 on Drizzle:
> https://answers.launchpad.net/drizzle/+question/60680
> just curious.
> thanks

The question is, why not just use SQLite which is specifically suited
for embedding.
It's tiny, and very functional.

Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com.au)
MySQL Training from $475/day, DBA/Support from $249/month

My blog is at http://arjen-lentz.livejournal.com
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org

Arjen Lentz wrote:
> Question #60680 on Drizzle changed:
> https://answers.launchpad.net/drizzle/+question/60680
>
> Arjen Lentz proposed the following answer:
> Hi wade
>
> On 12/02/2009, at 7:35 AM, wade wrote:
>> New question #60680 on Drizzle:
>> https://answers.launchpad.net/drizzle/+question/60680
>> just curious.
>> thanks
>
>
> The question is, why not just use SQLite which is specifically suited
> for embedding.
> It's tiny, and very functional.

The answer to this is, oddly, for concurrency reasons.

SQLite is wonderful and can be used for many things as long as two
different apps don't need to talk to the same SQLite db. However,
multiple iPhone apps accessing the same SQLite database start to
bottleneck because of its database-level locking. (I have a friend doing
iPhone apps who has already run in to this)

Granted- concurrency issues on a phone seems crazy to me... but I
imagine I'm more and more wrong each day on that.

Monty

On 12/02/2009, at 8:03 AM, Monty Taylor wrote:
>> The question is, why not just use SQLite which is specifically suited
>> for embedding. It's tiny, and very functional.
>
> The answer to this is, oddly, for concurrency reasons.
>
> SQLite is wonderful and can be used for many things as long as two
> different apps don't need to talk to the same SQLite db. However,
> multiple iPhone apps accessing the same SQLite database start to
> bottleneck because of its database-level locking. (I have a friend
> doing
> iPhone apps who has already run in to this)
>
> Granted- concurrency issues on a phone seems crazy to me... but I
> imagine I'm more and more wrong each day on that.

I'll betcha their schema and/or query design and app behaviour is wrong.

It's just like trying to outrun bad design with bigger hardware.

Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com.au)
MySQL Training from $475/day, DBA/Support from $249/month

My blog is at http://arjen-lentz.livejournal.com
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org

Well, why perhaps a redesign might get them around concurrency issues, some observations:

-) concurrency on a single-tasking phone? (Or are you targeting only jailbroken phones?)

-) sqlite really really sucks on concurrency. The first "really" is for the documented stuff like database level locks. The second one is for implementation stuff. e.g. eating quite a bit CPU while doing nothing but futex linux syscalls, that are triggered by concurrent access.

On the practical side, MySQL seemed to have supported an embedded (serverless) mode, if compiled so? Does it still have that?

Andreas

> On the practical side, MySQL seemed to have supported an embedded (serverless) mode,
> if compiled so? Does it still have that?

yes, the libmysqld embedded server library still exists, it was in a bad state though in the 5.0 release and so never officially supported there, but with MySQL 5.1 it is now officially supported again ... :

  http://dev.mysql.com/doc/refman/5.1/en/libmysqld.html