New Posts New Posts RSS Feed: Determining persistence order
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Determining persistence order

 Post Reply Post Reply
Author
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353
Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Topic: Determining persistence order
    Posted: 12-Jul-2007 at 3:34pm

You can use a different persistence order for each save.

Back to Top
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260
Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2007 at 3:34pm

Our persistence order issue is not for rows in the same table.  Rather it is in regards to a standard parent/child relationship between a parent table and a child table.  The default persistence order was working fine until recently, when suddenly it wanted to save the child before the parent.  For the specific parent/child relationship in question, we overrode the persistence order and that seemed to work fine.  However we then got an error for a different parent/child relationship. 

So our question is:  If we override the persistence order for a particular relationship, does that invalidate all of the other default persistence orders.  In other words, if we override one relationship persistence order, do we then have to override them all?

Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353
Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2007 at 3:33pm
 

Here is how Persistence Order is determined for any SaveChanges request:

(1)                 Typically, a default Persistence Order is determined for all of the tables which participate in the save.  The default order is determined automatically by doing a “reverse topological sort”.  In rare cases, this may not be the order that you want, and if that is the case, you can override this Persistence Order with your own Persistencce Order,

(2)                 Deletions occur first on a table-by-table basis.  Deletions occur in reverse Persistence Order.

(3)                 Adds and updates follow next and at the same time on a table-by-table basis according to the Persistence Order.

(4)                 Within a given table and within a given SaveTable operation (Delete versus Add/Modify), there is no predictable order.

Some comments on your observations:

(1)                 Your comment that there is no predictable Persistence Order between child records and parent records is correct if child and parent records belong to the same table.

(2)                 The typical way to handle limitations of Persistence Order is to make multiple saves.  This is a problem if you want to do the save as a single transaction.  Here is a coment from our senior architect on the issue of setting dependencies among or ordering records of the same type when performing a save:

This is a hard problem.  We currently have no way of setting dependencies among or ordering records of the same type when performing a save.  What we actually do internally is a DataAdapter.Update() call for each individual table, and this method iterates through the data rows without regard to contents.  We don’t currently plan to change this logic, so let’s see if a workaround will be sufficient. 

Back to Top
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260
Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jul-2007 at 3:31pm

For a few weeks now, we have been receiving very inconsistence foreign key constraint errors from the DB.  After viewing SQL Profiler, it appears that child records are trying to be saved prior to the parent record, thus causing the constraint errors. 

Sometimes we get the errors, sometimes we don’t.  We haven’t found any consistency.

Is there a way to determine what DevForce is using for the order with which it attempts to persist to the database? And how DevForce determines this order?

Are there any known issues with PersistenceOrder that we might work around?

Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down