|
From: Oleg B. <ph...@ph...> - 2013-10-16 22:25:52
|
On Wed, Oct 16, 2013 at 10:58:24PM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> 2013/10/16 Oleg Broytman <ph...@ph...>
> > > It does what I need, but it doesn't seem like it's what SQLObject
> > > developers intended. Do you have any recommendations?
> >
> > I don't. Do you want to propose an API? Or better a patch?
>
> Hey, thanks for the reply. I'm looking at the code right now, I need
> to look more carefully at the current structure before I can suggest
> an API or a patch. In general, I can see 4 possibilities:
>
> - when creating a connection, add an option to not cache that connection
That would be easy, just one additional parameter in
connectionForURI: cache=True (or useCache or something like that).
The approach could lead to problems, though. Every SQLObject's
connection maintain its own cache of retrieved rows, so different
connections for the same URI will have different caches, so the same row
could appear in a few caches; that would lead to unsynchronized
read/write operations.
> - add an option to clear / expire all the connections in the current cache
What gives? Usually if there are a few connections with different
URIs the user needs all of them.
> - add an option to the close() method so it causes the connection (and
> the URI) to expire from the cache
Not sure it could be implemented reliably. Connection doesn't know
its own DB URI, and reconstructing it could give an equivalent but
different URI.
> - there already is special handling for in-memory databases, so
> maybe add a little more special handling for them; for example free
> the memory on close().
That's a good approach; requires testing.
> This could potentially break existing
> applications, does SQLObject make any guarantees about in-memory
> databases?
Not much. I don't know anyone who uses the memory database for any
purpose other than testing.
Oleg.
--
Oleg Broytman http://phdru.name/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
