Persist Generics

[srf]

Ive been given a challenge from one of our domain developers to
persist a class that is a generics type. I havnt found a way to do it
so Im not sure if its totally possible. This is an example of a class
Im trying to persist:

Public class Foo<T>
{
...

}


Foo<myClass> m_class = new Foo<myClass>();
session.save(m_class);

is it possible to persist a class like this, if so what kind of
mapping would I create?If not what other options would I have given
the domain developers say if nhibernate cant persist generics then why
use it, so failure isnt an option for me.

thanks

scott

[Fabio Maulo]

2008/6/28 srf <scott...@cmgl.ca>:

is it possible to persist a class like this, if so what kind of
mapping would I create?If not what other options would I have given
the domain developers say if nhibernate cant persist generics then why
use it,  so failure isnt an option for me.

Not is not possible so far.
If you think that you can't have a domain without using generic NH is not for you.

Bye.
Fabio Maulo

P.S. When you have 10 minute ask to you why ~20000 app. can with NH, and something like that, or more, can with Hb.

[Fabio Maulo]

I forgot something....
In one app I have generic association but with a syntax like:
class StronglyAssociation : Associable<AClass>
The class StronglyAssociation have different business rules adding or overriding rules of  Associable.

In some other cases (long to explain) I'm using <any>.

But if your friend can't write his domain without using generic entities and he really absolutely need it, so far, NH is not an option.

Would be very useful to know when and why a Foo<T>, talking about app entities, is useful and then write some articles about ORM<T> theory.
Perhaps Scott W. Ambler can help us to think about it.

Fabio Maulo

[Ayende Rahien]

http://www.ayende.com/Blog/archive/2007/11/14/NHibernate-and-Generic-Entities.aspx

[srf]

thanks ayende, the possible solution you gave I think I could work
with. They use generics but 90% of the time they are going to use 5
different implementation of the generic so I can just define those
into the mapping document as you described and add to the mapping as
new types come up. The big question is if there are only going to be 5
different types why not impement 5 concrete classes of that type. I
had proposed that and they just like the flexability of allowing the
user to use any type in the generic they like. Idno, it seems kind of
strange but I got shot down and my mandate it to support anything and
everything the domain develops come up with and they have come up with
some wild designs that I have to persist. In this instance we have a
class called Array<T> so they want to be able to construct an array of
any type. One of those types could also be a Column<T> class so you
could end up with a Array<Column<Scalar<double>>> to create a grid of
doubles of type Metres as its quantity type. I suspect its a little
generics overkill but these are phd scientists designing this and its
hard to tell them they are wrong. The solution you gave me really
helps though so Im going to give that a shot and see what I come up
with.

thanks

scott

On Jun 28, 3:58 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> http://www.ayende.com/Blog/archive/2007/11/14/NHibernate-and-Generic-...

[Ayende Rahien]

I would ask why they need this type of thing, because this make the domain much harder to understand.
They are not gaining flexibility here, they are increasing complexity.

[srf]

EXACTLY!!! could you explain that to them because I cant seem to get
this across to them. And this is only a small example of the
complexity they came up with.

scott

On Jun 28, 10:23 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> I would ask why they need this type of thing, because this make the domain
> much harder to understand.
> They are not gaining flexibility here, they are increasing complexity.
>

[Ayende Rahien]

Contact me off the list. I am open for consulting right now.

[Marcus Cuda]

I'm not sure their model is that bad. I'm working on something
similar and spending the weekend to see if NHibernate will support it.
In my case, I have a set of data collections that contain a set of
variables that contain a set of observations. These roughly line up
with your array= data collection, column=variable, and
scalar<T>=observation<T> (with variable defined as variable<T> so all
observations are of the same type for a given variable). You need
this kind of flexibility since the number and type of variables is
different for each data collection and data collections can be created
on the fly. Originally I was only going to use a binary file format
to store the data, but with a database it is easier to share data
amongst users and put the data on the web.

For the database, I have tables such as DataCollection, Variable,
DoubleValue, ...the rest of the primitive types...DateValue,
StringValue, ObjectValue. The XXXValue tables hold all the different
types of observations. ObjectValue is stored as a BLOB and used as a
catch all to hold things like images. The XXXValue tables have a
reference to the Variable that owns them and Variable has a reference
to the DataCollection owns it. With a couple joins you have fully
populated DataCollection object. This actually works well for a had
rolled DAL I've written. Now I just need to see if I can get all the
NHibernate goodness.

There are several details I've left out to keep this short. If you
end up staying with the current model, feel free to contact me and I
can share the rest of the details.

Marcus

On Sun, Jun 29, 2008 at 4:13 AM, srf <scott...@cmgl.ca> wrote:
>

[srf]

thanks, but being in Calgary I think there might be a Nhibernate
course here put together by James Kovacs this summer so I might try
and and see if I can get in on that and see where that goes. The main
problem Im faced with is the negitive opinion of Nhibernate with the
domain developers because they think nhiberate is dictating how they
can design the domain objects like this issue with generics but I
found it exposes the problems with how they are designing the domain
model. There are other issues but Im pushing to get some consulting in
to help with these issues but Im still working on it with managment.

thanks

scott

On Jun 28, 7:17 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> Contact me off the list. I am open for consulting right now.
>

[srf]

sure, could you let me how you ended up designing the nhibernate
mapping files or how you plan on tackling it since I couldnt find
anything very working other than the solution ayende came up with
here. I tried creating special user types and perstence mapper types
but I ended up going down this ugly slippery slope that made the
persistence very unstable so I would be interested in how you end up
aproaching it anyhow.

thanks

scott

[Jay Chapman]

Well, I have done something similar to this as well.  I didn't do it for entities per se, but I did use it for components of entities.  Basically I created my own distance/area/volume classes which were IMeasurement<T> with Distance<T>, Area<T> and Volume<T>.  Where T could be int, decimal, double, whatever so long as it was a value type.  Basically I didn't want to limit the consumers to just a deciaml type since it may be used in calculation heavy areas.  I didn't want to limit them to doubles since it may be used in strictly data entry scenarios as well.

Then whichever type you use you just need to account for it in the mapping files.  I used a component since it was the simplest mapping.  However, these were value types which wound up causing head aches with components as once you made it nullable things got very complex.

[srf]

Thanks, I also Implemented this solution mentioned by Ayende and it
worked great and it solved my problem quite well.

thanks

scott

On Jun 30, 7:14 am, "Jay Chapman" <jayc...@gmail.com> wrote:
> Well, I have done something similar to this as well.  I didn't do it for
> entities per se, but I did use it for components of entities.  Basically I
> created my own distance/area/volume classes which were IMeasurement<T> with
> Distance<T>, Area<T> and Volume<T>.  Where T could be int, decimal, double,
> whatever so long as it was a value type.  Basically I didn't want to limit
> the consumers to just a deciaml type since it may be used in calculation
> heavy areas.  I didn't want to limit them to doubles since it may be used in
> strictly data entry scenarios as well.
>
> Then whichever type you use you just need to account for it in the mapping
> files.  I used a component since it was the simplest mapping.  However,
> these were value types which wound up causing head aches with components as
> once you made it nullable things got very complex.
>