Hi!

Maybe I missed this one, but I wonder what happens when you reference same (EntityClass) object from more than one object.

I am using 1.0.20051.51222 version, Adapter scenario.

For example, if same PersonEntity object is referenced by different objects (i.e. CarUser and Employee). (I have situation which is not easy to explain, so I made this example up.) When trying to save objects recursively, only one object is saved, the other is not. If I make a clone of PersonEntity and reference it by "the other" (not saved) object, it is saved properly.

Can one object be referenced by more than one?

Thanks.

Please check the IsDirty flag after the first save.

If this doesn't help you please post a code snippet of what your trying to do.

Thanks.

Sorry, I didn't make clear what the problem is. PersonEntity is saved properly, but objects referencing it weren't saved properly (one was saved, the other wasn't).

The object which wasn't saved had IsNew flag set to true, and I even flagged all fields as changed, but the INSERT statment for it wasn't generated.

If this doesn't help you please post a code snippet of what your trying to do.

It isn't easy because the code is spread across many classes.

After the first save: Did you try to set IsDirty = true of the referenced Entity. So that it could be saved on the second save?!

If you have 3 entities, A, B and C, and A references C and B also references C, and you call save on A, and all are dirty, first C is saved, then A, then B. It doesn't matter if you reference C from 1 or 100 entities, it is saved once of course, as you have just 1 object.

Though if in your setup, and you call save on A, and C is saved, and A is saved but not B, it's an issue, but it's a basic graph, and the code should handle any kind of graph, so it's a bit of a puzzle what is wrong?

Please elaborate on your setup a bit more, it's now too vague to get a clear picture.

Otis wrote:

Please elaborate on your setup a bit more, it's now too vague to get a clear picture.

Well, this obviously couldn't be avoided .

The project I'm working on is "Register of Business Entities" (where Business Entities stand for Enterpreneurs (EnterpreneurEntity as subtype of BusinessEntityEntity)). All Enterpreneurs are registered through Submissions (RegistrationEntity as subtype of SubmissionEntity). Registration can be submitted (we call him the Presenter and it is reference to PersonEntity) by enterpreneur founder (EnterpreneurFounderEntity which has ). When Presenter is declared to be enterpreneur founder, and SubmissionEntity's reference to Presenter is set, automatically EnterpreneurFounderEntity with PersonEntity set should be added to Founders collection in EnterpreneurEntity object (using method AddFounder implemented in EnterpreneurEntity class).

Previously mentioned PersonEntity object which is set as reference is fetched from database and it's IsDirtyand IsNew flags are set to false .

When SubmissionEntity object is saved recursively, everything is saved except EnterpreneurFounderEntity which references same PersonEntity as SubmissionEntity (even other EnterpreneurFounderEntity objects are saved properly).

Since rule for adding EnterpreneurFounderEntity when setting Submission.Presenter can be performed only if Founders collection on EnterpreneurEntity object is empty, I tried changing SubmissionEntity's reference to Presenter. It kept the same EnterpreneurFounderEntity previously added, and in that situation EnterpreneurFounderEntity was saved.

The other situation in which everything worked well is when PersonEntity set to added EnterpreneurFounderEntity was clone of object set as Presenter.

So, it appeared to me that only when both Submission and EnterpreneurEntityFounder reference exactly the same PersonEntity object.

I hope this explains everything I wanted.

Before I go any further, please check if all relations in the model are both ways. If not, make both ways/unhide the relations on one side so a relation is both ways

knez wrote:

Otis wrote:

Please elaborate on your setup a bit more, it's now too vague to get a clear picture.

Well, this obviously couldn't be avoided .

The project I'm working on is "Register of Business Entities" (where Business Entities stand for Enterpreneurs (EnterpreneurEntity as subtype of BusinessEntityEntity)). All Enterpreneurs are registered through Submissions (RegistrationEntity as subtype of SubmissionEntity). Registration can be submitted (we call him the Presenter and it is reference to PersonEntity) by enterpreneur founder (EnterpreneurFounderEntity which has ). When Presenter is declared to be enterpreneur founder, and SubmissionEntity's reference to Presenter is set, automatically EnterpreneurFounderEntity with PersonEntity set should be added to Founders collection in EnterpreneurEntity object (using method AddFounder implemented in EnterpreneurEntity class).

I have a bit of a problem following this one, but let's say I do, and the first thing I see which is odd is 'AddFounder'.

I mean, if enterpreneurfounderentity.enterpreneur is set to the enterpreneur object, enterpreneurfounder is automatically added to enterpreneur.founders (the relation is both ways, similar to order.customer = mycustomer, which will make order to be added to mycustomer.orders)

So why AddFounder is required is not clear. Also, Founders collection, is that a generated collection or a collection created by yourself?

Previously mentioned PersonEntity object which is set as reference is fetched from database and it's IsDirtyand IsNew flags are set to false .

When SubmissionEntity object is saved recursively, everything is saved except EnterpreneurFounderEntity which references same PersonEntity as SubmissionEntity (even other EnterpreneurFounderEntity objects are saved properly).

Strange. how is the relation between person and enterpreneurfounder btw? I don't have that clear, so I don't know if EnterpreneurFounder is part of a collection in Person. If not, it won't be saved.

Perhaps a small database model would clear up the sky. You can mail it to us directly at support AT llblgen.com if you don't want it to be posted here in the open.

Since rule for adding EnterpreneurFounderEntity when setting Submission.Presenter can be performed only if Founders collection on EnterpreneurEntity object is empty, I tried changing SubmissionEntity's reference to Presenter. It kept the same EnterpreneurFounderEntity previously added, and in that situation EnterpreneurFounderEntity was saved.

After this I got lost, sorry.

What the thing is with recursive saves is: all entities have to be in the same graph as the entity you save recursively. This means, all entities have to be either referenced (1:1 or m:1 relations) or in an entity collection (not your own collection) inside an entity. So if I save myOrder recursively, it will save myCustomer, IF myOrder.Customer == myCustomer and it will also save any entity referenced from myCustomer, IF those entities are in llblgen pro collections or normal entity references based on relations. It doesn't matter if an entity isn't dirty, it will then be skipped and the graph is futher checked.

Is your entity graph setup that way?

Thanks for the reply! I know that my problem explanation is yet another problem, so I really appreciate your effort to undestand anything I wrote.

Otis wrote:

Before I go any further, please check if all relations in the model are both ways. If not, make both ways/unhide the relations on one side so a relation is both ways

Well, relations were hidden on PersonEntity side (PersonEntity doesn't know anything about "context" it is used in). But, since recursive save works in all the other situations, I'm not sure if it would solve the problem. PersonEntity is not saved in recursive save with all the other objects, it is just being assigned to all objects which should be referencing it.

Otis wrote:

I have a bit of a problem following this one, but let's say I do, and the first thing I see which is odd is 'AddFounder'.

I mean, if enterpreneurfounderentity.enterpreneur is set to the enterpreneur object, enterpreneurfounder is automatically added to enterpreneur.founders (the relation is both ways, similar to order.customer = mycustomer, which will make order to be added to mycustomer.orders)

So why AddFounder is required is not clear. Also, Founders collection, is that a generated collection or a collection created by yourself?

EnterpreneurEntity has EntityCollection of EnterpreneurFounderEntity objects, but the idea of using AddFounder() method in EnterpreneurEntity object instead of EnterpreneurEntity.Founders.Add() is that EnterpreneurEntity object can control addition of it's founders (because sometimes it is not allowed to add more than one founder). I put some business logic in EntityClasses, so some sort of rules validation can be performed by objects.

Otis wrote:

Strange. how is the relation between person and enterpreneurfounder btw? I don't have that clear, so I don't know if EnterpreneurFounder is part of a collection in Person. If not, it won't be saved.

EnterpreneurFounder is person, but no inheritance was implemented. EnterpreneurFounder has relation 1:1 to PersonEntity. (Please don't ask me why is it like that!)

Otis wrote:

Perhaps a small database model would clear up the sky. You can mail it to us directly at support AT llblgen.com if you don't want it to be posted here in the open.

I was thinking that it would give me oportunity to explain everything from the beginning and with some diagrams (a picture is worth 1000 words, some say). As soon as I write down everything relevant to this, I'll send it to you.

I received your email. I'll look at it today

It turned out to be a nasty bug in the object graph sorter routine. Not likely someone will run into it, but it can be a graph isn't saved as expected. Here's the bug description:

If an entity A is reachable from an entity B via multiple paths, and the entity A is depending on an entity C on one of these paths and that entity C is already in progress but not yet processed, A isn't saved in all occasions if B is saved recursively. This is caused by the fact that ProduceTopologyOrderedList rightfully postpones the processing of A when it runs into it on one path from B, but after that doesn't re-process A again when it runs into it on another path from B because it mistakenly marked A as already processed.

Fixed in next build.