The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

data- pending->verify->staging

Hi, Pals

here is what our requirements is:
for every master data, we will go through a "pending->verfiy->staging" process, that means for every db create/update/delete, we need a "pending" state and then verify or reject this change.

Things become complex when the foreign key introduced. eg.

what if Parent has a list of children. Object model:

Parent
List<Child> children

THe "P-V-S" should also track when the chilren list changed.

Now, we got the solution to serialize all the object to xml, which will keep all it's details. But seems a little bit complex and code in other place were also polluted.

Can anyone give some hint? Thanks in advance.
Derek Zhang Send private email
Sunday, February 24, 2008
 
 
Is this prior to commit to the database, or even within the database?

If it's prior to commiting changes to the database, I believe this situation is well handled with the CSLA framework, as it offers full multi-level undo on a root object with children (with children, with children...).

Check it out at Ricky Lhotka's site.  Even if you don't want to use his framework, you can check out how it works by looking at the source.
Cade Roux Send private email
Sunday, February 24, 2008
 
 
That would be Rocky Lhotka, sorry for the typo.
Cade Roux Send private email
Sunday, February 24, 2008
 
 
Thanks! I will check it.

And my problem is not prior to the commit. That's why we have  to serialize it to an xml string.
Derek Zhang Send private email
Monday, February 25, 2008
 
 
I like to keep my object model and database model separate so that each can work the best for their environment.  In this case, the database has a variety of choices for representing a parent-child relationship in the data and the choice of which to use is going to depend a lot on the usage pattern.
Cade Roux Send private email
Monday, February 25, 2008
 
 
The CSLA.NET framework uses serialization extensively.

Once you get to the database, however, I've never had to model a process like this.

Are you saying you have to keep a new parent and child data as pending related to an old parent and child, and at some point a process confirms that data as valid and it is posted?

It almost seems easier to hold those in some kind of unposted version of the same tables than to have them interspersed with the regular data since it's not just one record with a state change.

I'm not sure of your actual usage pattern, but conceivably you could have an order with 5 lines already approved and this is changing to an order with 3 completely different line items which needs to be saved but is not yet approved.  Yet still, someone could act on the previously approved data, and then the new data should never be approved and would have to be backed out - if it was in a holding area, this could simply be discarded.
Cade Roux Send private email
Monday, February 25, 2008
 
 
Thanks Cade.

In my case: every record in db should have a "pending->verify->staging" process. In our object model, some object has parent-child relationship(just like order and orderline), the children's(or children's children's...) "pvs" process are part of parent's.

What I need is a clearcut and simple solution to handle this.
Currently, my solution is serialize the object to a xml node and saving in db.

We using hibernate,oracle,jee ( I know the tools do nothing with my problem, just for reference)
Derek Zhang Send private email
Monday, February 25, 2008
 
 
Can you not just have a status flag on the records that you set at each stage? 

e.g. add a boolean flag field called 'verified' that you set to true when the data is valid, and the staging process only pays attention to such records?
Dan Fleet Send private email
Tuesday, February 26, 2008
 
 
It appears that your business requirements are going to preclude simplicity.
Cade Roux Send private email
Tuesday, February 26, 2008
 
 
It's not uncommon to have separate sets of tables with similar schemas to represent objects in different stages of verification. 

Two advantages of segmenting this data:  First, you don't have to build views to filter unverified data out of queries on your final tables.  Second (and often this is the deciding factor) the preliminary tables can have different (laxer) constraints than the final tables.

For instance, if you're receiving records that contain some kind of natural foreign key, like a customer abbreviation, and those records are coming in from some sort of non-interactive source, you need to be able to save a row even though its customer abbreviation is wrong.  You can't move that row to the production table until the foreign-key mismatch is resolved, but in the meantime you have a place to persist the row until it's corrected.

There are ways to implement this in a single table, but they're inelegant.  For each foreign key the table needs have two columns, one containing the unverified value and one containing the verified one; there's only a foreign-key constraint on the latter.

There's one reason that you might want to adopt something like that:  typically, INSERTs are the most expensive operations you can perform on a table.  If you have some interactive process where users are editing and approving a large number of objects (and consequently many parent and child rows), you can find yourself with many users simultaneously executing long-running INSERT transactions on your production tables.  That can be trouble.
Robert Rossney Send private email
Tuesday, February 26, 2008
 
 
I think the requirements I have starred are driving the complexity:

<< for every db create/*update/*delete, we need a "pending" state >>

What does it mean to hold a pending update separate from a record previously approved and posted?

Does that record need to be treated differently if there is a pending update (should such an order not be shipped because someone has a pending, but unapproved change, yet the order as it exists right now was approved already itself, is it wrong to ship it)?  In this case, there are a number of designs which would specifically flag a record in a certain state so that certain actions should not be taken, but I don't think there is a general case or simple pattern which can be applied here.

Can there be separate competing pending updates?

And the pending update records are all linked together themselves with joins just like the original records?

The business rules sound complex, and they will require a solution with a certain complexity once these questions or similar are answered.  A clearer statement of your required usage patterns and expectations will probably lead you to a better design.
Cade Roux Send private email
Tuesday, February 26, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz