I have a good number of database tables with a pair of dates. BeginDate and EndDate representing a range.

I would like to map those two fields in to a custom immutable type called DateRange.

This would allow me the business logic validation that involves the decisions around including range, overlapping range etc..

Is there any way to achieve that mapping in LLBLGen?

Not at the moment, this is coming in v3. In v3 you will be able to define value types which can be created from any number of fields (and also be typed of value types) and they are mapped inside an entity to fields.

v3 is scheduled to be released later this year.

Otis wrote:

Not at the moment, this is coming in v3. In v3 you will be able to define value types which can be created from any number of fields (and also be typed of value types) and they are mapped inside an entity to fields.

Value Types didn't make into 3.0, are they going to be in 3.1? I ask because we would use it them if they were there.

It was the first item we worked on for 3.1, but it became clear we had a big problem designing them in with respect to selfservicing, because fields in selfservicing contain their persistence logic. It goes too far to explain it all here, but we had to make a choice and decided to leave it out the API so they won't be coming to our own framework. It's a choice we don't like at all, but it's something we unfortunately have to live with, similar to the fact that adapter was developed after selfservicing which should have been the other way around.

Otis wrote:

It was the first item we worked on for 3.1, but it became clear we had a big problem designing them in with respect to selfservicing, because fields in selfservicing contain their persistence logic. It goes too far to explain it all here, but we had to make a choice and decided to leave it out the API so they won't be coming to our own framework. It's a choice we don't like at all, but it's something we unfortunately have to live with, similar to the fact that adapter was developed after selfservicing which should have been the other way around.

That's is a shame I guess to much trouble to support then in adapter only?

Just wondering that if we really wanted value types would using CLR UDT's in SQL Server achieve the same end?

Not that it would help us much since you don't support Oracle UDT's.

TomDog wrote:

Otis wrote:

It was the first item we worked on for 3.1, but it became clear we had a big problem designing them in with respect to selfservicing, because fields in selfservicing contain their persistence logic. It goes too far to explain it all here, but we had to make a choice and decided to leave it out the API so they won't be coming to our own framework. It's a choice we don't like at all, but it's something we unfortunately have to live with, similar to the fact that adapter was developed after selfservicing which should have been the other way around.

That's is a shame I guess to much trouble to support then in adapter only?

It would have been a problem there too, but a bit less. It's a problem which comes with 'designing a feature after years of production': it's much much harder to add a feature at this point in the lifecycle of the framework than it would have been if we had designed it in from the get go. Valuetypes felt so tacked on that we didn't want to go there. Our framework also doesn't fit very well with the valuetype concept, as the valuetype classes themselves would have been classes with base-classes, field objects etc, so pretty 'big' while one would want to define them as a very tiny class.

Just wondering that if we really wanted value types would using CLR UDT's in SQL Server achieve the same end?

valuetypes are typically used to group fields together, like Address fields into 'Address', firstname/lastname into 'Name' etc., and to re-use that type in multiple entities. It's not really useful to have a valuetype with just 1 field in it, you can validate the field in an entity validator just fine. In that light, UDTs are not a substitute for valuetypes: they don't group multiple fields together which you can query on separately (e.g. ... where c.Address.Country==myCountry...). So it's not a substitute. UDTs are used to define data in a certain type which separate sub elements aren't used in a query separately.

Not that it would help us much since you don't support Oracle UDT's.

Oracle UDTs are indeed something we don't support yet, although Oracle made it simpler to support them in recent ODP.NET versions. It's on our list to look at though.