I finally got time to read about adapter.

Sort of shocked I must admit. I really liked the one liner:

dim customer as New CustomerEntity(19)

versus the new 3 line version.

Do I understand correctly that the main advantages of using an Adapter if we decide to is: 1) superparent.save() can orderly save any dirty child properties 2) control of connect, command properties

???

Is there a config or a way that I can get adapter type functionality to get the concurrency advantage for example, and then still use the one liner:

Dim customer as New CustomerEntity()

???

Thanks, as we are just handling concurrency now. Any hints on old or new config, finding the method to override to get our concurrency defined? We just want simple update timestamp checking that handles race conditions. With or without Stored Procedures.

tvoss wrote:

I finally got time to read about adapter.

Sort of shocked I must admit. I really liked the one liner:

dim customer as New CustomerEntity(19)

versus the new 3 line version.

Heh It's indeed not servicing itself, so it requires a little more work.

Do I understand correctly that the main advantages of using an Adapter if we decide to is: 1) superparent.save() can orderly save any dirty child properties

This is being ported back to SelfServicing as well. In fact, I've just finished implementing this in SelfServicing (all tests went ok) and will be available soon (have to add some more changes to selfservicing as well)

2) control of connect, command properties ???

Among other things. Adapter is not for people who want to have the most easy to use dal layer, as it requires more work (thre is no load-on-demand, you have to create teh adapter object yourself etc.). However the ease-of-use of selfservicing also comes with a price: it is pretty limited if you want to create a class hierarchy from the derived classes. It's also pretty limited if you want to support multiple database systems using a single entity set (as some people are doing: supporting both oracle and sqlserver in one application). Selfservicing can also be a no-go if your organisation demands that objects used in the GUI shouldn't be able to persist themselves (some organisations demand this) so GUI developers have to use the BL classes to get things done which automatically avoids errors in teh application because some developer took a shortcut due to a deadline . Adapter is also the better template group for remoting scenario's where you don't need persistence logic on the client anyway.

It's about how you look at things: if persistence behaviour should be part of the object itself, selfservicing will be more appealing. If you look at it in the way that persistence behaviour is added to your object as a service, adapter is more appealing. With the 2 types, the choice is there.

tvoss wrote:

Is there a config or a way that I can get adapter type functionality to get the concurrency advantage for example, and then still use the one liner:

Dim customer as New CustomerEntity()

??? Thanks, as we are just handling concurrency now.

I'm not completely sure what you mean by concurrency in this context. If you mean the save(predicate) and delete(predicate) stuff as well as the recursive saves with the IConcurrencyPredicateFactory implementation, this will be available in selfservicing soon.

Any hints on old or new config, finding the method to override to get our concurrency defined? We just want simple update timestamp checking that handles race conditions. With or without Stored Procedures.

You can do that now already, by using Save(predicateExpression) instead of just Save()

Yes, I meant handling update of save with a timestamp.

I understand and that overload of save is great, but this company wants, if possible w/o too much dev-time, to force the concurrency version of save()

Is save implemented in the inherited level where I could alter it to always use the overload? and automate the creation of the filter?

And handle the possible race condition that could occur between seeing if the timestamp property has changed and doing the update like I assume you have handled in your overload of save?

tvoss wrote:

Yes, I meant handling update of save with a timestamp. I understand and that overload of save is great, but this company wants, if possible w/o too much dev-time, to force the concurrency version of save() Is save implemented in the inherited level where I could alter it to always use the overload? and automate the creation of the filter?

Yes, you can use the 2 class scenario and override UpdateEntity() and in that overload, you call UpdateEntity(predicate) instead of MyBase.UpdateEntity()

In the soon to be released selfservicing updates, you will have a new interface IConcurrencyPredicateFactory which you can implement in a class. You tehn can create an instance of that class and store that object in the entity, which then will be used to provide a save predicate when you call Save() (adapter already has this).

And handle the possible race condition that could occur between seeing if the timestamp property has changed and doing the update like I assume you have handled in your overload of save?

You can specify a comparevalue predicate with the save, where you compare teh timestamp field with the value the timestamp field has in teh entity you're saving, and the predicate will be added to the update query and will then cause a fail if the timestamp column is different.

The fail will be a false value returned by save, right?

not an exception?

Thanks for all this help. Very helpful.

tvoss wrote:

The fail will be a false value returned by save, right?

not an exception?

Thanks for all this help. Very helpful.

It will just add the predicate with AND to the where clause of the UPDATE statement (and the where clause will already contain the predicate which filters on the PK fields). In the case of a missing timestamp value, the update will affect 0 rows, and thus save will return false