On Sep 21, 2006, at 10:51 AM, Wolfgang Keller wrote:
>
> I was wrong here. PostgreSQL notifications don't require polling
> the database
> server. It's just the libpq client library itself that requires
> polling a
> function to retrieve the notifications.
>
> But an example for Psycopg2 show
On Sep 21, 2006, at 10:51 AM, Wolfgang Keller wrote:
>> mike wrote:
>> if someone wants to write an extension, most easily to
>> sessioncontext, that just synchronizes data between open sessions,
>> thats not a big deal. But it really is somewhat of a reinvention of
>> the database itself. the
>> For such cases, Modeling provides a mechanism that
>> "broadcasts" changes made by one "editing context" to all others upon
>> committing. Maybe they could share code with SQLAlchemy?
>
> if someone wants to write an extension, most easily to
> sessioncontext, that just synchronizes data be
On Sep 20, 2006, at 9:33 AM, Wolfgang Keller wrote:
> For such cases, Modeling provides a mechanism that
> "broadcasts" changes made by one "editing context" to all others upon
> committing. Maybe they could share code with SQLAlchemy?
if someone wants to write an extension, most easily to
s
>> I forgot to mention that what I have in mind are not several instances of
>> SQLAlchemy, but a single instance which would be part of something like
>> an "application server". Then all client requests would be processed by
>> one and the same instance of SQLAlchemy, running on the server
On Mon, 18 Sep 2006 20:09:48 +0200
Wolfgang Keller <[EMAIL PROTECTED]> wrote:
> Just because I don't want to have to take care of all this "transaction
> management" myself, as this is complete rocket-science to me...
I know not of ACID, but... rocket science this is not.
trans = session.create
On Sep 19, 2006, at 8:19 AM, Wolfgang Keller wrote:
>
> I forgot to mention that what I have in mind are not several
> instances of
> SQLAlchemy, but a single instance which would be part of something
> like an
> "application server". Then all client requests would be processed
> by one and
Hello,
> as far as basic transactional sanity, its reasonable; we imitate the
> constructs used by Hibernate. in a concurrent environment,
I forgot to mention that what I have in mind are not several instances of
SQLAlchemy, but a single instance which would be part of something like an
"ap
as far as basic transactional sanity, its reasonable; we imitate the
constructs used by Hibernate. in a concurrent environment, its not
possible to insure that objects in memory are always exactly in sync
with the database, without going back to the database to refetch the
data, or by pess
Hello,
as a lazy Python scripting dilettant who's looking for a persistence
framework for database applications, I was wondering whether SQLAlchemy does
transparently ensure that all transactions will always be as ACID as the
underlying database (PostgreSQL in my case) allows. Among others, whe
10 matches
Mail list logo
