On Dec 24, 2007, at 6:23 PM, Adrian Klaver wrote:
> First this based on using the full Dabo framework db-->bizobj-->ui
> 1) Create bizobj.
> Serves as 'template' for communicating with db and ui.
> Also serves as local data store.
> 2) Create ui form and controls.
> Actually this could happen before 1).
> Form elements can receive data from the bizobj as well as other
> sources
> 3) When requery() is called form afterInitAll the bizobj is
> populated with data from
> the DataSource i.e database table. The ui in turn uses this data to
> fill the data controls.
> At this point there are two versions of the data. One resident in
> the database table,
> the other resident in the form.
Well, it's actually in the bizobj/cursor combo, but that's not an
important distinction here.
> For some time, albeit it possibly brief, they are the same.
> 4) Changes are made to the form resident data. update() is used to
> populate the form controls
> when navigating in the form. At this point the form data is
> different from the database data.
As it should be, since the user just changed it.
> 5) It is possible that changes have been made to the database table
> outside of the scope of the
> Dabo app. Again this means the db data and the form data have
> diverged.
That's true in any multi-user situation
> 6) When save() is run the changes in the form are propagated back
> to the database via the bizobj. requery() propagates changes in the
> db to the bizobj and hence to the ui. This is where I run into a
> problem.
> Problem:
> Open form with data. Make change in form field from Dabo app. Make
> committed change in same record but different field from outside
> app i.e. psql. From form do save(). Database has Dabo changed field
> updated. Do requery() , db is queried but non-Dabo change is not
> shown until an update() is done. Why?
If the outside change was to a different field than the Dabo change,
you will certainly see it if you run a requery(). Perhaps you're
assuming that save() also runs a requery()? That wouldn't be possible
to program, since form.save() calls either bizobj.save() or
bizobj.saveAll(), depending on the setting of form.SaveAllRows, and
requerying after saving just one row could possibly lose changes in
other rows.
> Shouldn't the requery() pull in all the new data. If point 3 is
> correct then the new form resident data should equal the db
> resident data after the requery().
Yes, that is correct, and I just verified it with MySQL. I grabbed a
record, changed one field in Dabo, and before saving, changed a
different column using phpMyAdmin. I then saved the change in Dabo,
and saw only the Dabo version. I then requeried, and then saw the
changed I had made in phpMyAdmin.
The sort of thing you are describing is typical contention issues
that are common in all multi-user situations; they are not unique to
Dabo. Database backends each have different means available for
dealing with contentions that vary from ignoring the issue ("last one
wins") all the way to pessimistic transaction locking.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
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]
