On Dec 23, 2007, at 9:56 PM, Adrian Klaver wrote:
> 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.
I can understand your confusion, especially if you've never
developed in a client-server manner before.
> 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?
It's not so much a cache as it is a separate copy. The purpose of a
cache is to speed up multiple accesses of the same data, whereas the
copy in the bizobj is supposed to be distinct from the database, so
that you can modify it, sort it, do whatever you want to it... and
then discard those changes without affecting the actual data in the
database. The only way to affect the database is through save() or
delete().
> 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.
While such a setup may sometimes be a good thing, the general rule
is that anything that is potentially destructive to the data must be
explicit. Users in general should be able to make a change and only
save it when they want to.
> I have greater faith in a database table holding data than an
> application.
On a long-term basis, of course. But your app should only be holding
a very small amount of data at any given time, right?
> My inclination is to make the data hit the database soon and often.
Have you ever developed a client-server app with thousands of users?
If you took that approach your app would not be very responsive. The
more efficient approach is to grab just the data you need, display/
modify it locally, and then save the changes back only when you want
to. That's what Dabo's data access is designed to do: we buffer local
data completely, so that even with parent-child relationships, the
child data is buffered even when you move the parent pointer.
> From poking around I can see ways to make that happen, I just have
> to work out the procedure.
You could hook into the bizobj's beforePointerMove() method, which
fires (as the name suggests) before the current row pointer moves to
the new record:
def beforePointerMove(self):
self.save()
-- 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]
