Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Uniform Field Update for All Entities?
 

Pages: 1
LLBLGen Pro Runtime Framework
Uniform Field Update for All Entities?
Page:1/1 

  Print all messages in this thread  
Poster Message
psandler
User



Location:
Chicago, IL
Joined on:
22-Feb-2005 22:24:13
Posted:
540 posts
# 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
My C#/SQL Blog (some LLBL content)
Email: psandler70 (at) yahoo.com
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37643 posts
# 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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
psandler
User



Location:
Chicago, IL
Joined on:
22-Feb-2005 22:24:13
Posted:
540 posts
# 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


My C#/SQL Blog (some LLBL content)
Email: psandler70 (at) yahoo.com
 
Top
jeffreygg
User



Location:
Stockton, CA USA
Joined on:
26-Oct-2003 05:53:24
Posted:
805 posts
# 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...


LLBLGen Pro Version: 2.6
Runtime Library Version: 2.6.8.1013
 
Top
psandler
User



Location:
Chicago, IL
Joined on:
22-Feb-2005 22:24:13
Posted:
540 posts
# 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. Regular Smiley

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


Cheers,

Phil
My C#/SQL Blog (some LLBL content)
Email: psandler70 (at) yahoo.com
 
Top
jeffreygg
User



Location:
Stockton, CA USA
Joined on:
26-Oct-2003 05:53:24
Posted:
805 posts
# Posted on: 26-Apr-2005 01:42:06.  
psandler wrote:

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


Cheers,

Phil


Hah! Story of my life. Regular Smiley

Jeff...


LLBLGen Pro Version: 2.6
Runtime Library Version: 2.6.8.1013
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37643 posts
# 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.

Quote:

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 Regular Smiley), 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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
psandler
User



Location:
Chicago, IL
Joined on:
22-Feb-2005 22:24:13
Posted:
540 posts
# 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)


My C#/SQL Blog (some LLBL content)
Email: psandler70 (at) yahoo.com
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37643 posts
# Posted on: 26-Apr-2005 23:27:50.  
Laugh. Glad it works Phil!
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.