Hi,

After an insert, why is an entity considered out of synch?

Cheers, I.

So that any database activity; identity columns, triggers, ... will be reflected in your entity. Otherwise after you commit you may have incorrect information and not know.

bclubb wrote:

So that any database activity; identity columns, triggers, ... will be reflected in your entity. Otherwise after you commit you may have incorrect information and not know.

I wish this could be turned off...like you would want if you knew there where no triggers, etc.

If you want to may set entity.Fields.State property to EntityState.Fetched

mikeg22 wrote:

bclubb wrote:

So that any database activity; identity columns, triggers, ... will be reflected in your entity. Otherwise after you commit you may have incorrect information and not know.

I wish this could be turned off...like you would want if you knew there where no triggers, etc.

Honestly, I don't think you want that. First of all: what if there are default constraints on a field and you insert null ? Or better: first they're not there, and you have switched this off, and then they're introduced, but you'll never see the value back in the entity.

Otis wrote:

mikeg22 wrote:

bclubb wrote:

So that any database activity; identity columns, triggers, ... will be reflected in your entity. Otherwise after you commit you may have incorrect information and not know.

I wish this could be turned off...like you would want if you knew there where no triggers, etc.

Honestly, I don't think you want that. First of all: what if there are default constraints on a field and you insert null ? Or better: first they're not there, and you have switched this off, and then they're introduced, but you'll never see the value back in the entity.

You're right, but isn't that the responsibility for the developer (and not for LLBLGen) to make that decision?

It always is, but history learns that they also mostly first come to us complaining something doesn't work. Thing is that these kind of issues could be created without you noticing it.

In theory, the entity object in memory doesn't contain the real entity, the data is stale, it has to be refetched, IF you want to re-use the data inside that entity object.

If you don't want to re-use that entity object anymore, it's ok, you won't get a / need to do a refetch.

I must say I fail to see why an out-of-sync is such a problem. After all, the entity object isn't the entity, it's a container. The container's data is outofsync with the real entity, that's what the state is saying and that's correct. So switching it off makes it be not correct.

As walaa suggested, you can set the state if you want to, however I fail to see why you would ever want to do that.

Otis wrote:

It always is, but history learns that they also mostly first come to us complaining something doesn't work. Thing is that these kind of issues could be created without you noticing it.

In theory, the entity object in memory doesn't contain the real entity, the data is stale, it has to be refetched, IF you want to re-use the data inside that entity object.

If you don't want to re-use that entity object anymore, it's ok, you won't get a / need to do a refetch.

I must say I fail to see why an out-of-sync is such a problem. After all, the entity object isn't the entity, it's a container. The container's data is outofsync with the real entity, that's what the state is saying and that's correct. So switching it off makes it be not correct.

As walaa suggested, you can set the state if you want to, however I fail to see why you would ever want to do that.

Well, in our application we don't use triggers that affect the fetched graph, and we don't use default values as defined in the db. Refetching forces us to either rebind to all our controls after a save or do what we ended up doing, which is by keeping our original entity references, but setting their states to indicate they have been refetched. There is also the issue of the performance hit of the refetch combined with the serialization time of our (rather large) entity graphs. We don't want our users to have to wait 5 seconds every time they hit the save button...

I understand but at the moment that's the way it is. As said, you can set the entitystate if you need this manually, so you can avoid running into the outofsync issue.

I can see the logical problem this causes, because the state of the entity can be fetched or OutofSync. After saving a dirty entity, it doesn't really make sense to clear the dirty flags and call it "fetched" after that point...so, I guess I see your dilemma. Maybe if the state could be "InSync" it would make more logical sense, and after a save the state could be set to InSync. I could see an entity being considered in sync with the database after an update (or insert) statement if you can assume the update/insert just did what you told it to do (as in our application).

Oh well, I know this issue probably isn't going to lead to a LLBLGEN code-breaking change, so I'll just be happy with our solution of "faking" the refetch