On Sunday 23 December 2007 9:47 pm, johnf wrote:
> On Sunday 23 December 2007 08:20:56 pm Adrian Klaver wrote:
> > On Sunday 23 December 2007 8:03 pm, johnf wrote:
> > > > > The source is the bizobj; i.e., the 'DataSource'. The update()
> > > > > method is called frequently; it would not be wise to have it
> > > > > constantly requerying the database.
> > > >
> > > > I sort of understand. Let me see if I can work this out. In my case
> > > > the bizobj refers to a table (which from the documentation is the
> > > > 'default' use) so I saw the table as the DataSource, not the bizobj.
> > > > What you are saying is that the bizobj as the middleware component
> > > > caches data in its structure and update() works on that structure and
> > > > requery() works on the underlying table. Am I getting close?
> > >
> > > Yes it sounds good to me!
> > >
> > > > If my assumptions above are correct I can see how this would be a
> > > > problem. To play the Devils advocate I prefer that data is
> > > > automatically saved when moving from record to record. I have greater
> > > > faith in a database table holding data than an application. My
> > > > inclination is to make the data hit the database soon and often. From
> > > > poking around I can see ways to make that happen, I just have to work
> > > > out the procedure.
> > >
> > > Not my cup of tea but as you have discovered Dabo is very flexible and
> > > should beable to work for you. Don't forget you are working with
> > > Postgres and you will have to consider changing the way transaction
> > > processing is handled.
> >
> > I am not sure I follow. My experience with Psycopg is that is very fast
> > and that doing small transactions is not an issue.
>
> I doubt there would be a performance issue.
>
> Maybe I mis-understood what you are saying and reading to much into your
> earlier questions. It sounded like you wanted to override the way Dabo
> currently updates records. Dabo only updates what has been changed and only
> when a save() occurs. This works well with the default way Postgres works
> - no lock until a commit and the isolation level is 'Read Committed'.
> However, if you are scrolling up and down a grid and writing to the backend
> for each change of record pointer and you want others to see the changes.
> You will run into some sort of locking issue.
I would only be writing those records that have changed by using the isChanged
method, not for each change of the pointer. See answer to locking issue
below.
>
> If you use pgAdmin3 try this:
> Open a Dabo app and make sure you requery() to get data. Now view the
> table from pgAdmin and make a change from the view on the same record and
> try to move the record pointer with the down/up arrow. pgAdmin hangs -
> right! Now close the Dabo app. pgAdmin writes the data.
No. pdAdmin3 ver. 1.7.0. Things work as I would expect. Each app sees its own
snapshot of the data and changes data without interfering with the other. I
made concurrent changes to the same field in the same record and saw the
changes reflected in both apps upon commit. The biggest problem I have with
Psycopg2 is that by default its behavior is:
ISOLATION_LEVEL_READ_COMMITTED
This is the default value. A new transaction is started at the
first .execute() command on a cursor and at each new .execute() after
a .commit() or a .rollback(). The transaction runs in the PostgreSQL READ
COMMITTED isolation level.
Unfortunately this behavior extends to SELECT statements. So you can get into
a situation where you have a lot of open transactions, especially if clients
are just doing SELECTS.
For most situations READ COMMITTED is more than adequate and allows for
concurrent access without issue. This leads me to another question. Is it
possible to override the transaction level from within the app?
--
Adrian Klaver
[EMAIL PROTECTED]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
