On Sep 11, 2008, at 8:53 AM, Federico Fanton wrote:
> What about optimistic concurrency control, then? Versioning wouldn't
> require a per-DBMS customization, isn't it?
Each backend handles concurrency and locking differently. The
approach we've taken in Dabo is to raise exceptions when the result of
a database operation fails. The exception should be handled at the
bizobj layer, where you can add your own logic for each type of
exception. There is no logic built into the framework for this, as we
felt that no one approach would be able to handle every possible
application.
> So Dabo doesn't prevent an approach like that, great :) (And I just
> found dAutobizobj...)
Early on someone asked why we don't provide a full front-end for DB
management. My response was that there are many tools out there that
do that for each database server, and there is no way we could do it
better than those tools. So we focused on the stuff that wasn't
available elsewhere. If someone was sufficiently motivated, they could
add their own tool, such as dAutoBizobj.
>> Logical deletion is more of a database design than a bizobj design,
>> since the bizobj is concerned with the logic, and thus logical
>> deletion == deletion. To implement logical deletion, you'd need to
>> add
>> that flag field to the database, and then subclass dBizobj to always
>> add 'delflag = 0' or the equivalent to every query.
>
> So I'd have to have a look at dBackend too, I see..
Not necessarily. You could add a property to your bizobj that is a
flag for whether to include 'deleted' records or not. Then in your
beforeRequery() hook method, add some logic to add a WHERE clause to
filter out these records if one was not already present if that flag
property is set, or to remove it if it isn't.
> Another question if I may: implementing logical deletion requires that
> the persistence layer "emulates" the DBMS to prevent deletions at the
> end of not-null relations and the like, does dabo.db provide means for
> such checks, that I could use? (metadata of the relations..? )
Hmmm... we have flags for relational integrity settings, but nothing
that would correctly handle this situation. The bizobj referential
checking merely checks if a child bizobj has records, not if there are
any related 'deleted' records that are in the DB but not in the child
dataset. Look through dBizobj for 'deleteChildLogic',
'updateChildLogic', and 'insertChildLogic' for how we handle this at
this level.
Another possible approach is to set the integrity rules in your
RDBMS, and catch/handle the error if you attempt an operation that
violates these rules because of the presence of logically deleted
records.
> It's true, but fortunately in our business domain this isn't
> required..
> More than that, it must be prevented :) For example, if there's an
> "Invoice" object that references a "Customer" object, and I modify the
> Customer, the business rules need the Invoice to keep referencing the
> "old" customer data.
> In the event that I want the Invoice to reference the new one, I'd
> update the Customer and then contextually update its reference inside
> Invoice.
Understood. I developed a similar system for a medical records
company once. In that case, we didn't delete the old patient records;
we simply had a master patient record and a 1:1 patientInfo record;
when the information changed, we added a new patient info record, and
updated the pointer in the master table. Historical records, though,
pointed to the info record, not the master, as these were never changed.
I think that this whole exercise also shows how difficult it is to
create a framework that can handle all possible applications. So what
we've attempted to do is create a framework that handles the routine
stuff for you, and still make it easy to customize with the particular
requirements of each app you create. Please keep asking these sorts of
questions, as it makes us re-examine our previous design decisions,
and possibly improve the existing code.
-- Ed Leafe
_______________________________________________
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/[EMAIL PROTECTED]
