Sqlite :memory: database for production?

[Subsume]

Hey there,

I've got an app on my site that's a game where people make picks from
Pack objects. These objects only exist during the life of the game
(about 20 minutes) and then are gone. I'm hoping to reduce some Disk I/
O on my server by allowing this app to use a database that is purely
in sqlite memory.

I see all kinds of efforts for people to use such an in-memory sqlite
database during tests but how would this work live? I'd need all my
web-server processes to share this database.

Right now I've got the name :memory: but the table always seems to be
empty, despite objects being created.

Is my approach off? Maybe I should I try some other way to create my
sqlite file in debian's mounted ram space?

[Javier Guerra Giraldez]

On Mon, Nov 29, 2010 at 10:10 AM, Subsume <sub...@gmail.com> wrote:
> Right now I've got the name :memory: but the table always seems to be
> empty, despite objects being created.

from the docs (http://www.sqlite.org/inmemorydb.html):

> Every :memory: database is distinct from every other. So, opening two database connections each with the filename ":memory:" will create two independent in-memory databases.

--
Javier

[Subsume]

Yeah I gathered that but I found some django code that seemed to deal
with that:

http://code.djangoproject.com/ticket/2658

I wasn't sure what the implications of this would be in a live
situation.

On Nov 29, 11:05 am, Javier Guerra Giraldez <jav...@guerrag.com>
wrote:

[Cal Leeming [Simplicity Media Ltd]]

Hi,

To be honest, if you're that worried about performance and concurrent user handling, then you wouldn't be using SQLite anyway. Please can you explain some details about what you are trying to achieve, and lets see if we can give you a better solution :)

Cal

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--

Cal Leeming

Operational Security & Support Team

Out of Hours: +44 (07534) 971120 | Support Tickets: sup...@simplicitymedialtd.co.uk 
Fax: +44 (02476) 578987 | Email: cal.l...@simplicitymedialtd.co.uk 
IM: AIM / ICQ / MSN / Skype (available upon request)

Simplicity Media Ltd. All rights reserved.

Registered company number 7143564

[Subsume]

I'm not really worried about concurrent user handling. I'm more
worried about things happening quickly.

Basically take 3 objects: Pack, Card, Pick. A user is handed a Pack
with many Cards, they make a Pick and hand the Pack to the next user.
Eventually the Pack depopulates of Cards and deletes itself.

Right now making sure the transaction happens smoothly takes a lot of
little queries. Just trying to speed this process up.

-Steve

On Nov 29, 1:31 pm, "Cal Leeming [Simplicity Media Ltd]"

> > django-users...@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.
>
> --
>
> Cal Leeming
>
> Operational Security & Support Team
>

> *Out of Hours: *+44 (07534) 971120 | *Support Tickets: *
> supp...@simplicitymedialtd.co.uk
> *Fax: *+44 (02476) 578987 | *Email: *cal.leem...@simplicitymedialtd.co.uk
> *IM: *AIM / ICQ / MSN / Skype (available upon request)

[Sells, Fred]

Is there an easy way to get django to email error tracebacks in the
pretty html format that it uses when Debug=True?

I've got it emailing plain text, but that requires I "reconstruct" the
url from the query string while the html version had it nicely presented
-- not the end of the world, but would be nice.