In my project, I have tables with a LastUpdtTime field which records the time of the last record update (duh). I want to verify that any updates to entities in this table have had no intervening changes.

So my plan is to define a concurrency predicate on that table so that LLBLGen can enforce that policy. (I further plan to make that field ReadOnly, so no coding inadvertently updates it.)

Now the second half of this is to have a update trigger defined that will set that LastUpdtTime field to current system time during the update. I'm assuming that Self-Servicing will then read back the new value when the entity is refreshed.

My next requirement is that any updates to this table are logged to a separate (history) table. My update trigger will be responsible for reading the current values from the database record being updated and inserting a new record with those values in my logging table. The PK of that newly created log record is then placed in a FK field of the primary table to provide a link to the previous values.

Given these requirements, is this the way to do this in an LLBLGen environment? Would it be better to have the update trigger handle the concurrency also (instead of using LLBLGen)?

Thanks in Advance!

So you are using the datetime to ensure that the last record in the history matches your current version in the table before your trigger will proceed with the update? If that is the case I would put that in the trigger so that any and all ways that the table could by updated are covered by the logic that you need.

Here is the table structure:

Customer CustomerID_PK PreviousVersion_FK Name Address City State Country LastUpdtTime

CustomerHistory CustomerID_PK PreviousVersion_FK Name Address City State Country LastUpdtTime

In the Customer table, PreviousVersion_FK references CustomerHistory.CustomerID_PK. In the CustomerHistory table, PreviousVersion_FK _also _references CustomerHistory.CustomerID_PK.

This establishes a linked-list in the database, the Customer table only holds current records, but each may have a reference via the PreviousVersion_FK to the most recent previous version. In CustomerHistory, PreviousVersion_FK holds a reference to the version before this one. This linked-list ends when PreviousVersion_FK is null, indicating the original version of the Customer record inserted.

So, I'm planning to use a ConcurrencyPredicate to address the need to detect intervening changes (via the LastUpdtTime field). And the update trigger will take care of the copying of the (about to be no longer current) version of the Customer record to the CustomerHistory table. Note that only the PreviousVersion_FK of the incoming Customer record will be affected by the trigger (setting it to the value of CustomerHistory.CustomerID_PK of the record inserted into CustomerHistory.)

Having explained this, I'm becoming convinced that it will work, but does anyone see any gotcha's?

I don't see any problems, only that you should be aware that saving teh history entity isn't what you should do as the trigger will take care of that. In the code the history entity is probably available (as you want to fetch it).

Thanks Otis.

One last question (maybe)...

I've defined my PredicateFactory class in the generated Entity class. And I'm adding the predicates to an instance of the Entity class in the "InitClassFetch" and "InitClassEmpty" which seems to cover all the bases. However, are those the right places? Am I missing any situation?

CvilleCoder wrote:

I've defined my PredicateFactory class in the generated Entity class. And I'm adding the predicates to an instance of the Entity class in the "InitClassFetch" and "InitClassEmpty" which seems to cover all the bases. However, are those the right places? Am I missing any situation?

No those are the places. You can init an entity there