[ZODB-Dev] Relstorage Database Adapter

[Shane Hathaway]

On 11/24/2010 05:17 AM, Santi Camps wrote:
> Hi all
>
> I'm using relstorage for a long time with very good results.  Until
> know, I also use database adapters like ZPsycopgDA to connect the same
> SQL database and store information in other application tables.   I was
> thinking to create a Relstorage Database Adapter able to do the work
> using relstorage configuration and connections.   Some preliminary
> simple tests seems to work:
>
> def execute_query(conn, cursor, *args, **kw):
>      query = kw['query']
>      cursor.execute(query);
>      return cursor
> query = 'SELECT COUNT(*) FROM kmkey_task'
> rows = app._p_jar._storage._with_store(execute_query, query=query)
> print rows.fetchone()
>
>
> The question is, can I go on ?  Or use same connections than relstorage
> could cause problems at ZODB level ?

Well, it doesn't look like you're using the two RelStorage connections 
the way they are intended to be used.  For the code snippet you gave, 
it's likely that you want to use the load connection rather than the 
store connection.

The load connection ensures consistent reads.  RelStorage does a number 
of things to maintain that guarantee.  The load connection is never 
committed, only rolled back.

The store connection is intended to be used only during transaction 
commit.  At the beginning of a commit (tpc_begin), RelStorage rolls back 
the store connection in order to get the most recent updates.  The store 
connection and load connection are often out of sync with each other, so 
code that uses the store connection should detect and handle conflicting 
updates.

I suspect the load/store connection split is too complicated for most 
apps that just want to interact with the database, so I haven't exposed 
any documented API.  I considered making an API when I worked on 
repoze.pgtextindex, but I concluded that pgtextindex can be a bit lazy 
about consistency and therefore doesn't need all the extra complexity 
that reusing RelStorage connections would bring.

Shane