[PATCH 5/7] Re: Don't keep sqlite connections open

[Nicolas Sebrecht]

On Fri, May 06, 2011 at 08:59:11AM +0200, Sebastian Spaeth wrote:

> I agree that factoring that out would be nice, but... ( :-) )
> ... I really don't want to put that into this topic series. I have been
> spending plenty of time in refining each of the patches (always doing
> 'git rebase -i next')

Notice this would mean a new commit /on top/ of the topic.

>                        and the series is already as big as I am
> comfortable with a series.

I can understant.

> How about we think about merging this as is now, and work on a followup
> series that builds on what we have and factors out whatever is
> possible. For example, we still don't know if this approach [opening and
> closing the db for each transaction] is scalable at all or whether we
> don't need a "db owning thread" that we pass the data to. I'd rather
> gather some data from others first.
> Alternatively, it got pointed out that *newer versions* of sqlite can
> access the db from multiple threads. I would love to find out *how new*
> that version must be and improve our design to not always close and open
> our database first before embarking on more architecture design.

Ok to me.

> >     * statements including additional code to execute: pass both the
> >       request and a function to the wrapper
> 
> Mmmh, I am not really sure I get this yet, can you give an example? What
> additional code could you be thinking off? Are you thinking of something like
> 
> def savemessageflags(UID, flags):
> 
>  res = data.write(SQL     ='UPDATE status flags=:flags WHERE UID=:UID',
>                   sqlargs ={UID:1,flags:'T'},
>                   func=<a function that does something (with what?)>)

I was thinking of passing a lambda function, for example. This gives
wider possibilities for the caller.

> > I think the SQL topic is a very good opportunity for improving our data
> > driver design. In short, I would expect something like data.write(),
> > data.read(), (...).
> 
> mmmh, I would think that the current system already provides quite a bit
> of abstraction by providing overridable classes for each backend for
> each functionality, but I would be happy to get a discussion started on
> what and how to improve things. But I still feel that is someout out of
> the scope of this topic series.

I was talking about the potential. :-)

-- 
Nicolas Sebrecht