Re: [SQLObject] reading and writing to different database instances

I'm pretty sure you can pass a connection around and set a connection when you create and instance and that it will use that connection for the life of that instance. I'm not sure if you can change the connection once you have an instance. I haven't had to do this, but it's something I think Ian

Re: [SQLObject] reading and writing to different database instances

On 8/1/06, Dustin Lee <[EMAIL PROTECTED]> wrote: Is it possible to configure sqlobject so that it can select from one server and do insert/update/deletes on possibly another server (or generally just choose where any one given sql instruction will be executed)?  The background is that we are moving

[SQLObject] reading and writing to different database instances

Is it possible to configure sqlobject so that it can select from one server and do insert/update/deletes on possibly another server (or generally just choose where any one given sql instruction will be executed)?  The background is that we are moving to a multi-coast/continent replication scheme wi

Re: [SQLObject] SelectResults internal

On Tue, Aug 01, 2006 at 11:46:41AM -0500, Luke Opperman wrote: > P.S. Oleg, SF Patch 1524615 is the last outstanding issue with synchronization > that I'm aware of, the problem it solves was introduced with the close > argument to Transaction.commit(). With that applied, the docs for the next > rel

Re: [SQLObject] SelectResults internal

That restriction was based on the lack of synchronization of instance caches, applied in r1581 & a further fix in r1683. As I recall, those are both after 0.7. However, if you are *exclusively* using transactions (don't have a main plain connection whose instance cache matters), you can still use

Re: [SQLObject] SelectResults internal

On Tue, Aug 01, 2006 at 06:17:31PM +0200, Didrik Pinte wrote: > From what i've heard/read, because I need transaction support on those > tables, I can't use an sqlmeta.cacheValues=True. > > Question for the list : is it (still) true ? I think it's an outdated requirement. I use transactions wi

Re: [SQLObject] SelectResults internal

Le mardi 01 août 2006 à 09:50 -0500, Luke Opperman a écrit : > > Then, a query for each getattr : > > 1/QueryOne: SELECT thastate_id FROM validdata WHERE id = 78 > > 1/QueryR : SELECT thastate_id FROM validdata WHERE id = 78 > > 1/COMMIT : auto > > 1/QueryOne: SELECT tsastate_id FROM vali

Re: [SQLObject] Connections and transactions - not consistent with DBAPI v2?

Please answer to the mailing list. On Tue, Aug 01, 2006 at 03:12:24PM +0200, Iwan Vosloo wrote: > So, I can happily create Transactions and let my 3rd party system pool > THEM as if they were connections (and thereby ignoring the connection > pooling done by SQLObject)? I think so. > Is it ne

Re: [SQLObject] SQLObject and MSSQL v6

On Tue, Aug 01, 2006 at 09:35:41PM +0700, Basil Shubin wrote: > Does a SQLObject support the MSSQL version 6? SQLObject uses DB API drivers to connect to a backend. For MSSQL it uses adodbapi or pymssql. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]

Re: [SQLObject] SelectResults internal

> Then, a query for each getattr : > 1/QueryOne: SELECT thastate_id FROM validdata WHERE id = 78 > 1/QueryR : SELECT thastate_id FROM validdata WHERE id = 78 > 1/COMMIT : auto > 1/QueryOne: SELECT tsastate_id FROM validdata WHERE id = 78 > 1/QueryR : SELECT tsastate_id FROM validdata W

[SQLObject] SQLObject and MSSQL v6

Hi friends, Does a SQLObject support the MSSQL version 6? Thanks! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business

Re: [SQLObject] SelectResults internal

Le mardi 01 août 2006 à 13:56 +0400, Oleg Broytmann a écrit : > > > That's why it's so slow. I've 4.10^6 rows with 8 states per row. That > > means 7* 4.10^6 unwanted queries. > >You certainly don't want to process them row by row. It would be too > slow in any case. Unluckily, I have to ;-)

Re: [SQLObject] SelectResults internal

On Tue, Aug 01, 2006 at 11:26:48AM +0200, Didrik Pinte wrote: > Ok, so it means that the following code will always require two queries > in the same table in order to get the foreign key value ? > > # select the row > vdata = validata.select(AND(validdata.q.stationID == station.id, > validdata.q.

Re: [SQLObject] Connections and transactions - not consistent with DBAPI v2?

On Tue, Aug 01, 2006 at 10:50:16AM +0200, Iwan Vosloo wrote: > And I may want to rollback > and start a new transaction several times - all using that same > reference. Which can be done with PEP249 connections, but not with a > sqlobject.Transaction... (because it becomes obsolete) You can "r

Re: [SQLObject] SelectResults internal

Hi Oleg, Thank you for the clear explanation. I've added some comments and questions below : Le mardi 01 août 2006 à 12:32 +0400, Oleg Broytmann a écrit : > On Tue, Aug 01, 2006 at 07:47:48AM +0200, Didrik Pinte wrote: > > [1] vdata = validdata.select(AND(validdata.q.stationID == station.id, > >

[SQLObject] Connections and transactions - not consistent with DBAPI v2?

Hi there, I'd like to verify my understanding of connections and transactions - it seems they work differently to DBAPI v2 connections. I'd also like feedback on my proposed solution for a local problem...which needs connections and transactions to behave as per DBAPIv2. Just want to make sure I

Re: [SQLObject] SelectResults internal

On Tue, Aug 01, 2006 at 07:47:48AM +0200, Didrik Pinte wrote: > [1] vdata = validdata.select(AND(validdata.q.stationID == station.id, > validdata.q.mtime == row.mtime))[0] > > then I parse the states in this row with the following code : > > [2] for state in states: > getattr(vdata, state)