Uniform Field Update for All Entities?

Posts   
 
    
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 21-Apr-2005 18:32:04   

Hey Frans,

I was wondering if there is a way to cycle through all the dirty (or new) entities in a fetched entity graph.

Here is the whole of the problem we are trying to solve. For every entity in the database, we have two UserID fields, one for the user who created the record, and one for the user who last updated it. These field names and relations are completely uniform.

Right before I recursively save, I would like to call a method that walks the graph and finds every dirty entity. If the entity is new in addition to being dirty, it would set the createdBy field value to the logged in user id. Then it would set the updatedBy field to the same userid.

Is this possible? Is there a better way to apply an update like this uniformly?

We currently have this working, but we test isnew/isdirty after updating all the fields of each entity. This isn't really in a ton of places, but we would prefer to do it in once place to make the operation as uniform and consistent as possible.

As always, thanks for any insight.

Phil

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 22-Apr-2005 09:46:10   

If you're using adapter, you could derive a class from DataAccessAdapter, override SaveEntity() and in there set the userid if the entity is changed.

If you want to walk the graph yourself: each entity has a GetDependentRelatedEntities (m:1, 1:1 where the current entity is on the FK side), GetDependingRelatedEntities (1:1 where the current entity is on the PK side) and GetMemberEntityCollections (1:n where the current entity is thus on the PK side). Simply keep track of ObjectID's in a hashtable so you know which one you've already seen.

Frans Bouma | Lead developer LLBLGen Pro
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 25-Apr-2005 20:23:12   

Awesome, thanks! I'm going to try to implement this later today.

Semi-related question: is it possible to abstract prefetch paths in a similar manner?

For example, if every entity had an identical relationship to the user table, would it be possible to create a generic function for adding that prefetch path to an entity before fetching?

I'm hoping that question makes sense. It's kind of hard to articulate.

Thanks,

Phil

jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 25-Apr-2005 22:35:34   

Frans: I haven't tried it myself, but doesn't the adapter raise events before and after save. If so, could psandler hook the events and walk the graph there?

psandler: If you just need access to some properties on an entity that's related in a 1:1 manner, the new property mapping functionality might be a better solution than prefetching the whole entity. Just a thought. Info is in the docs at: "Using the designer::Adding and editing entities::Fields mapped on related fields sub tab"

Jeff...

psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 25-Apr-2005 23:31:46   

jeffreygg wrote:

Frans: I haven't tried it myself, but doesn't the adapter raise events before and after save. If so, could psandler hook the events and walk the graph there?

psandler: If you just need access to some properties on an entity that's related in a 1:1 manner, the new property mapping functionality might be a better solution than prefetching the whole entity. Just a thought. Info is in the docs at: "Using the designer::Adding and editing entities::Fields mapped on related fields sub tab"

Jeff...

Thanks Jeff--I'll take a look at this. I haven't had the opportunity to upgrade to the new version yet, but there are several new features that are going to make my life much easier, so I'm looking forward to it greatly. simple_smile

I just need to trim down my current "to do" list first. frowning

Cheers,

Phil

jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 26-Apr-2005 01:42:06   

psandler wrote:

I just need to trim down my current "to do" list first. frowning

Cheers,

Phil

Hah! Story of my life. simple_smile

Jeff...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 26-Apr-2005 12:14:10   

jeffreygg wrote:

Frans: I haven't tried it myself, but doesn't the adapter raise events before and after save. If so, could psandler hook the events and walk the graph there?

That's called on a per-entity basis, so the graph is walked the way he wants indeed. The problem is though that teh OnSaveEntity() method is called after the query is already created. So doing something in the OnSaveEntity() routine is too late for the entity the OnSaveEntitymethod is called for.

psandler: If you just need access to some properties on an entity that's related in a 1:1 manner, the new property mapping functionality might be a better solution than prefetching the whole entity. Just a thought. Info is in the docs at: "Using the designer::Adding and editing entities::Fields mapped on related fields sub tab" Jeff...

You still need to fetch the related entity, as the data for the related field is read from the related entity object. It's not an optimized way to map an entity on multiple tables (not yet simple_smile ), as the fields mapped on related fields aren't part of the entity they're defined in (they're not part of the fields object)

Frans Bouma | Lead developer LLBLGen Pro
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 26-Apr-2005 22:24:08   

Otis wrote:

If you're using adapter, you could derive a class from DataAccessAdapter, override SaveEntity() and in there set the userid if the entity is changed.

This worked nicely! Woohoo!

The mind boggles at the potential of this. It seems to me you can avoid a lot of maintenance problems caused by using triggers by using this approach instead.

Thanks again,

Phil

(EDITED for typos)

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 26-Apr-2005 23:27:50   

smile . Glad it works Phil!

Frans Bouma | Lead developer LLBLGen Pro