My discomfort with the current API

[Paul Batum]

The last few times I've sat down to work on Fluent NHIbernate I've made very little progress. I've been trying to address issues regarding collections of type 'map'. At the moment maps are only supported for one to many and the functionality I wrote was very naive. I wanted to address this issue:

How to map Dictionary<enum1,enum2> with Fluent Nhibernate

I also wanted to apply a modified version of the patch supplied by Ngoc in:

Map and index-many-to-many

I say modified because Ngoc's patch deals with only one of several special cases regarding maps.

So thats what I've been trying to do. My difficulty arises in that I have been trying to look at these problems with a rather broad view. If Fluent NHibernate is to be "feature complete" at some point, we are going to have to have a way to support the rarer mappings that NHibernate enables. Rarer mappings such as these ternary examples from the NHibernate Collections docs:

<map name="Contracts" lazy="true">
    <key column="employer_id"/>
    <index-many-to-many column="employee_id" class="Employee"/>

    <one-to-many column="contract_id" class="Contract"/>
</map>

<map name="Connections" lazy="true">
    <key column="node1_id"/>

    <index-many-to-many column="node2_id" class="Node"/>
    <many-to-many column="connection_id" class="Connection"/>
</map>

I look at these and can't help but think that the concepts of "OneToManyPart" and "ManyToManyPart" are not the correct building blocks to be coming straight off the class map. A while ago I posted about the idea of the Fluent NHibernate API exposing methods such as HasBag, HasSet, HasMap rather than HasMany and now feel that the idea is worth revisiting. That said, I am not saying that we can't make it work well with HasMany and HasManyToMany, its just tricky at the moment because the underlying model isn't very rich. For example, OneToManyPart and ManyToManyPart do not share a base class so there is some significant duplication between the two (or lack of duplication, when I add something to OneToManyPart and -forget- to update ManyToManyPart accordingly, which is very often).

Put simply, I'm having trouble filling out the edge cases with our current model, and am concerned about its long term viability. Does anyone else share my concern? How would you ideally map those ternary examples? Here is the sort of thing I am thinking about:

class Employer
{
  public IDictionary<Employee, Contract> Contracts { get; set; }
}

class Node
{
  public IDictionary<Node, Connection> Connections { get; set; }

}

mappings:

employerMap.HasMap(x => x.Contracts)
  .WithIndex( indexMapping => indexMapping.ManyToMany())

  .WithEntities( entityMapping => entityMapping.OneToMany());

nodeMap.HasMap(x => x.Connections)
  .WithKeyColumn("node1_id")

  .WithIndex( indexMapping => indexMapping.ManyToMany("node2_id"))

  .WithEntities( entityMapping => entityMapping.ManyToMany());

This mapping would use MapPart (derived from CollectionPart), IndexPart, EntityPart (derived from CollectionItemPart) and KeyPart classes. Perhaps a nicer suffix than 'Part' could be found (such as 'Mapping') but hopefully that explains my thinking...

Feel free to tell me that I'm making a mountain out of a molehill if you think that is the case :)

Thanks,

Paul Batum

[Chad Myers]

In general, if it makes it easier to use externally and easier to code internally, I'm all for it.

One question: Will this make it easier or more difficult to do things 'conventionally' or with the auto-mapper type stuff? If it makes it easier, it's win-win-win and definitely worth spiking.

-c

________________________________

From: fluent-n...@googlegroups.com on behalf of Paul Batum
Sent: Mon 11/17/2008 9:51 AM
To: fluent-n...@googlegroups.com
Subject: [fluent-nhib] My discomfort with the current API


The last few times I've sat down to work on Fluent NHIbernate I've made very little progress. I've been trying to address issues regarding collections of type 'map'. At the moment maps are only supported for one to many and the functionality I wrote was very naive. I wanted to address this issue:

How to map Dictionary<enum1,enum2> with Fluent Nhibernate <http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/b5e90d500a046276/6feab18f24f3a0e0?hl=en&lnk=gst&q=How+to+map+Dictionary%3Cenum1%2Cenum2%3E+with+Fluent+Nhibernate#6feab18f24f3a0e0>

I also wanted to apply a modified version of the patch supplied by Ngoc in:

Map and index-many-to-many <http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/40f37669b2235d3f/3b28678edbfc46b7?hl=en&lnk=gst&q=index-many-to-many#3b28678edbfc46b7>

I say modified because Ngoc's patch deals with only one of several special cases regarding maps.

So thats what I've been trying to do. My difficulty arises in that I have been trying to look at these problems with a rather broad view. If Fluent NHibernate is to be "feature complete" at some point, we are going to have to have a way to support the rarer mappings that NHibernate enables. Rarer mappings such as these ternary examples from the NHibernate Collections docs <http://www.hibernate.org/hib_docs/nhibernate/html/collections.html> :

<map name="Contracts" lazy="true">
<key column="employer_id"/>
<index-many-to-many column="employee_id" class="Employee"/>

<one-to-many column="contract_id" class="Contract"/>
</map>
<map name="Connections" lazy="true">
<key column="node1_id"/>

<index-many-to-many column="node2_id" class="Node"/>
<many-to-many column="connection_id" class="Connection"/>
</map>

I look at these and can't help but think that the concepts of "OneToManyPart" and "ManyToManyPart" are not the correct building blocks to be coming straight off the class map. A while ago I posted <http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/bf456a9267d7dbd7/7c1408235e58dc8d?hl=en&lnk=gst&q=HasSet#7c1408235e58dc8d> about the idea of the Fluent NHibernate API exposing methods such as HasBag, HasSet, HasMap rather than HasMany and now feel that the idea is worth revisiting. That said, I am not saying that we can't make it work well with HasMany and HasManyToMany, its just tricky at the moment because the underlying model isn't very rich. For example, OneToManyPart and ManyToManyPart do not share a base class so there is some significant duplication between the two (or lack of duplication, when I add something to OneToManyPart and -forget- to update ManyToManyPart accordingly, which is very often).

[James Gregory]

Last time you raised the prospect of having HasMap (et al), I disagreed. I preferred the idea of not complicating matters with the type of collection, and merely letting the mappings determine what to use. For whatever reason this isn't the way it's ended up being used, and I realise that perhaps it wasn't feasible anyway; there are too many specific differences between the different collection types to be able to map between them in a interchangable manner.

If the changes you have in mind will improve our development experience, but also (and more importantly) improve the user experience, then I'm all for it. My only request would be that you develop it in a separate branch, so not to affect anyone using the current trunk too early on.

Do you have any kind of plan for how you'd like to tackle this?

-- James

[Paul Batum]

I am tempted to defer this matter until Chad has had a chance to follow up on his idea of passing NHibernate a model, rather than hbm xml. I suspect this change will drive a significant redesign that might also alleviate some of the pain I am experiencing. Even if it doesnt help my problems, I would still be better off waiting anyway. I'd rather not end up in a situation where we have two branches that are very difficult to reconcile.

Chad, any idea how you will proceed with that work? Could you use an extra hand?

[Chad Myers]

I spent about 6 hours this weekend going through and trying to convert ClassBinder.cs over to exclusively use Hbm* classes (i.e. HbmClass, HbmManyToMany, HbmProperty, etc) instead of passing “mystery meat” XmlNodes around.

 

I ended up having to give up because I got *WAY* too far down a rat hole.  About 3 hours into it, I realized that this is not going to be an effective strategy since there is simply too much XML “magic” going on.

 

I can give specific examples if anyone cares, but rest assured, it’s not as simple as I had originally thought. 

 

I’m starting to come to the mindset that the fastest way of accomplishing this task is to try to achieve as near 100% coverage of the XSD as possible and then gut the XML stuff. I know it sounds harsh, but it is simply TOO tied to XML for any other strategy to be effective.

 

One possible thought was to appeal to the community to send us as many models + HBM XML Maps + tests as possible to help us coverage as much ground as possible.

 

I’m still willing to do the effort, but I think that the work that needs to be done will not be accepted unless a good portion of the community is behind it.

 

Another possible option is to do the side-by-side mapping source that Fabio suggested, but this will essentially fracture the NHibernate mapping code and cause a schism.  Eventually the code bases will have unique bugs and features and maintenance will become prohibitively convoluted.

 

It’s my sincere hope that everyone eventually chooses to go with this new mapping source and it becomes the de-facto standard, allowing the XML mapping to eventually die (or become a 2^nd class mapping to the primary model-based mapping).

 

I’m loath to go down the schism road as I think it will be very painful and cause hard feelings among the community.

 

-c

[Paul Batum]

Chad,

My apologies, there is something I haven't quite followed properly. I suspect it is due to my lack of familiarity with the NH codebase. Why can't we proceed with modifying Fluent NHibernate to generate a model consisting of Hbm* classes , rather than xml? Surely NHibernate can consume a model built from the Hbm* classes because otherwise, why would those classes exist in the first place? Is this where I am mistaken? Even if NHIbernate cannot consume a Hbm* model, couldn't FluentNHibernate build a Hbm* model and then serialize it to xml? To be honest I don't really care if xml is involved somewhere or not. I just want to get away from our current approach of generating xml directly with procedural code - its not very maintainable.

I did spend a bit of time looking at the NH source but I must admit I struggled to understand how it fits together. Sorry for being dense.

(For other people's reference, this discussion is probably about to become a continuation of this thread).

Paul Batum

[Julian Birch]

I believe the problem is that the Hbm* classes are not true domain classes, but just classes generated by xsd.exe.  I've tried using those things before.  They're extremely XML specific and ugly to use.  Their only real advantage is that they do the C# to xml mapping  for you.

Julian.

2008/11/18 Paul Batum <paul....@gmail.com>

[Paul Batum]

Yes, the hbm classes need to be wrapped behind a richer interface. Its even possible that Fluent NHibernate would double wrap them, once as an internal API and a second time as the Fluent API. But unless I've grossly misunderstood, there is a deeper problem.

[Chad Myers]

Paul,

 

We could absolutely work against the Hbm* classes (or against a model on top of the Hbm* as Julian suggested) and then serialize to XML.  I don’t think the perf hit from going to Hbm to XML is that bad. The real hit is the XML Schema validation in NHibernate, which we have to deal with either way.

 

The problem I was trying to solve is to get NHibernate off of its XML addiction and  not have to incur the XML Schema validation tax, but this effort is a major effort and should be tabled for now (or the discussion should be moved to the NHibernate-devel list instead).

 

Back to Fluent NHibernate, If we’re going to get off of direct XML generation and switch to the Hbm* classes, then we should be aware of two things:

 

1.)    It will make it slightly more difficult and brittle to deal with XSD changes on the NHibernate side

2.)    It will be slightly more difficult to support multiple concurrent NHibernate versions

3.)    If NHibernate ever does change to not use XML, we’ll have to have a major rewrite (again).

 

Perhaps we could map to a semantic model that can translate to Hbm?  It sounds silly, but then we can use that model for other things (ORuM, backend entity data model, etc).

 

Thoughts?

 

Chad

[Fabio Maulo]

On 18 nov, 07:02, "Paul Batum" <paul.ba...@gmail.com> wrote:
> My apologies, there is something I haven't quite followed properly. I
> suspect it is due to my lack of familiarity with the NH codebase. Why can't
> we proceed with modifying Fluent NHibernate to generate a model consisting
> of Hbm* classes , rather than xml?

No; NH can't consume Hbm* classes. NH can consume classes of
NHibernate.Mapping namespace.

Surely NHibernate can consume a model
> built from the Hbm* classes because otherwise, why would those classes exist
> in the first place?

Because somebody start a work without end it (and using copy&paste).
Is was a good work but it is an "incopiuta" opera.

[Paul Batum]

Thanks for helping me fill in the gaps guys, I think I've got a pretty clear picture now.

Chad, I agree that Fluent NHibernate should utilize a semantic model. In an attempt to expand on your idea, here are some guidelines I think we should consider:

• The model should have a normal interface (i.e. NOT fluent).
• We also provide a fluent interface that writes to the model.
• The model should be exposable, and 100% complete and compatible with the NHibernate XSD. I don't want to have to turn people away and say "you have to write xml or modify the source yourself until we implement FOO" (like I had to when someone wanted index-many-to-many support) . The fact that we provided SetAttribute helped alot in this regard but it still wasn't perfect. If there isn't a fluent builder for a particular section of the model then people should be able to get at it and manipulate it so that the right xml is coming out.
• Xml generation is treated as a seperate concern and is not the responsibility of the rich model.
• Ideally, we have seperate unit tests for the fluent interface and the generation of xml from the model. This would mean the majority of our current unit tests would have to be rewritten.

So that all said, I would like to propose the following approach:

Fluent NHIbernate generates hbm xml using the Hbm* classes. Ulimately an object graph consisting of Hbm* instances is built and then serialized to xml. We know the Hbm* classes are generated from the schema and will therefore be up to date. If somehow someone figures out how to refactor the nhibernate classbinder to work with hbm classes then there will be an extremely easy path to removing xml from the process altogether, but things will still be fine if this never occurs.

The Hbm* classes are too raw and we can't extend them ourselves, so we need our own rich model that we have control over. It seems there are two ways to approach this: either the model wraps the Hbm* classes, and the Hbm object graph is built up as the mapping occurs, or the model stores everything itself and then -generates- the Hbm object graph when it comes time to output the xml. I suspect the former will prove to be a more practical approach because we can simply expose the Hbm graph as a "get out of jail free" card much like we do with SetAttribute today.

The fluent interface exists and looks much as it does today, and is implemented as a fluent builder on top of the rich model.

Is this basically what you were thinking of Chad? Or is this over architected (something I am often guilty of)?

At the risk of repeating myself, here are my justificiations for this proposal:

• It sucks when we have to tell people to hack on our code base or write xml when they ask about lesser known features of the nhibernate schema. How about the motto: "If NHibernate supports it, so do we".
  
• Writing code to generate xml sucks. Working against an object graph that can be validated as you go and serialized to xml is nicer.
  
• Its hard to reason about the capability of a library when only a fluent interface is exposed. All that nested lambda goo makes for nice calling code but comes with a cost when it comes to extending the library.
  

Thoughts?

Paul Batum

[Fabio Maulo]

Rewrite all Binders to consume only generated Hbm* classes is part of
my TODO-list since the end of 2007, for various reasons, but I would
like to do it when some others features will be implemented (as
refactoring of connection-transaction matters and EntityMode.Xml
support).
So far, the mix between Deserialized classes (Hbm*) and XmlNode is
something I don't like at all (less when I find copy&paste); perhaps
the real problem is the target of that refactoring: only performance.

On 19 nov, 09:51, "Paul Batum" <paul.ba...@gmail.com> wrote:
> Thanks for helping me fill in the gaps guys, I think I've got a pretty clear
> picture now.
>
> Chad, I agree that Fluent NHibernate should utilize a semantic model. In an
> attempt to expand on your idea, here are some guidelines I think we should
> consider:
>

>    - The model should have a normal interface (i.e. NOT fluent).
>    - We also provide a fluent interface that writes to the model.
>    - The model should be exposable, and 100% complete and compatible with

>    the NHibernate XSD. I don't want to have to turn people away and say "you
>    have to write xml or modify the source yourself until we implement FOO"
>    (like I had to when someone wanted index-many-to-many support) . The fact
>    that we provided SetAttribute helped alot in this regard but it still wasn't
>    perfect. If there isn't a fluent builder for a particular section of the
>    model then people should be able to get at it and manipulate it so that the
>    right xml is coming out.

>    - Xml generation is treated as a seperate concern and is not the

>    responsibility of the rich model.

>    - Ideally, we have seperate unit tests for the fluent interface and the

>    generation of xml from the model. This would mean the majority of our
>    current unit tests would have to be rewritten.
>
> So that all said, I would like to propose the following approach:
>
> Fluent NHIbernate generates hbm xml using the Hbm* classes. Ulimately an
> object graph consisting of Hbm* instances is built and then serialized to
> xml. We know the Hbm* classes are generated from the schema and will
> therefore be up to date. If somehow someone figures out how to refactor the
> nhibernate classbinder to work with hbm classes then there will be an
> extremely easy path to removing xml from the process altogether, but things
> will still be fine if this never occurs.
>
> The Hbm* classes are too raw and we can't extend them ourselves, so we need
> our own rich model that we have control over. It seems there are two ways to
> approach this: either the model wraps the Hbm* classes, and the Hbm object
> graph is built up as the mapping occurs, or the model stores everything
> itself and then -generates- the Hbm object graph when it comes time to
> output the xml. I suspect the former will prove to be a more practical
> approach because we can simply expose the Hbm graph as a "get out of jail
> free" card much like we do with SetAttribute today.
>
> The fluent interface exists and looks much as it does today, and is
> implemented as a fluent builder on top of the rich model.
>
> Is this basically what you were thinking of Chad? Or is this over
> architected (something I am often guilty of)?
>
> At the risk of repeating myself, here are my justificiations for this
> proposal:
>

>    - It sucks when we have to tell people to hack on our code base or write

>    xml when they ask about lesser known features of the nhibernate schema. How
>    about the motto: "If NHibernate supports it, so do we".

>    - Writing code to generate xml sucks. Working against an object graph

>    that can be validated as you go and serialized to xml is nicer.

>    - Its hard to reason about the capability of a library when only a fluent

>    interface is exposed. All that nested lambda goo makes for nice calling code
>    but comes with a cost when it comes to extending the library.
>
> Thoughts?
>
> Paul Batum
>

[Chad Myers]

Paul,

A true internal dsl uses/generates a clean semantic model in the end. Fluent NHib doesnt use a semantic mode and is pure generative which is why we keep bumping into
its limitations.

I agree with you that it is time to switch fluent nhibernate to be a ful internal dsl instead of just some method chaining and nested closure tricks.

I do not think that the semantic model should be directly XML serializeable, as this will bring a lot of pain due to the fact that the model will serve two masters (purposes). The semantic model should map (under the hood) to the HbmClasses or XML directly (not sure which will be better, we'll figure it out when it comes to that -- I'm thinking Hbm* for compiler support but that will be brittle and more version-specific which could cause support issues).

Perhaps now its time to take Fabio's suggestion and see if we can become a contrib project under NHibernate's umbrella?

Sounds like we're on the same page. There some implementation details yet remaining, but I'm confident we'll be able to work them out through the process.

So, how to you want to divide the labor?
----------------------
Sent from my phone. Please excuse typos and extra characters

-----Original Message-----
From: Paul Batum <paul....@gmail.com>
Sent: Wednesday, November 19, 2008 6:56 AM
To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: My discomfort with the current API

[Chad Myers]

Fabio,

This is good news! I'm glad to hear that this is an issue of concern. I totally understand the reluctance to do this since it's a big chunk of work.

Thank you for investigating this matter and explaining the current situation!

----------------------
Sent from my phone. Please excuse typos and extra characters

-----Original Message-----
From: Fabio Maulo <fabio...@gmail.com>
Sent: Wednesday, November 19, 2008 7:25 AM
To: Fluent NHibernate <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: My discomfort with the current API

Rewrite all Binders to consume only generated Hbm* classes is part of
my TODO-list since the end of 2007, for various reasons, but I would
like to do it when some others features will be implemented (as
refactoring of connection-transaction matters and EntityMode.Xml
support).
So far, the mix between Deserialized classes (Hbm*) and XmlNode is
something I don't like at all (less when I find copy&paste); perhaps
the real problem is the target of that refactoring: only performance.

On 19 nov, 09:51, "Paul Batum" <paul.ba...@gmail.com> wrote:

[Paul Batum]

Chad,

Agreed on all points, and given the choice I would prefer to try the Hbm* route as it will probably be quicker for getting us to the point where we can do a release (maybe I just think this because I hate generating xml by hand...). If it causes pain beyond that, then we could look at alternatives. It is also nicer given that Fabio does intend to implement Hbm* support for nhibernate.

My weekend is looking pretty chockers so if you were keen to get started soon I say just go nuts and we'll see how I can help next week. If you are prepared to wait I would be interested in the possibility of pairing, I haven't had the chance to remote pair before and would like to give it a go. I am actually inbetween jobs at the moment so the time zone differences will not be a problem (I think your 9pm is my 2pm).

Paul Batum

[LostGeorgian]

I have been lurking for a while - we have an internal auto-mapping
tool (closed source for now) that is much less flexible than fl-nhib
but we dealt with similar issues, so here are some thoughts for what
its worth.

1. Working with XSD.exe generated files is painful there are much
better generators -
http://www.microsoft.com/downloads/details.aspx?familyid=89e6b1e5-f66c-4a4d-933b-46222bb01eb0&displaylang=en
support for generics etc. What we do is generate our XML wrappers and
then create partials this makes it trivial to deal with upgrades to
the nhib schema. Regenerate the xsd wrapper classes and then patch
the partials.

2. We originally used the XSD generated classes to keep the ongoing
state of the model but found that to be painful ( in part because our
tool is a design-time tool and keeping the xsd wrappers in sync with
the IDE was difficult). Now we keep our own semantic model and only
generate the XML when needed (for us that is at build time).

3. A few simple interfaces on top of the generated XSD classes makes
the wrapper classes MUCH easier to deal with than raw XML (on top of
class and subclass, or most of the collection classes for example).

Hope that is useful - we are hoping to be able to contribute to the
Nhib community mid-next year but have to deal with some legal stuff
firstt.

Cheers,

Terence

> So that all said, I would like to propose the following approach:
>
> Fluent NHIbernate generates hbm xml using the Hbm* classes. Ulimately an
> object graph consisting of Hbm* instances is built and then serialized to
> xml. We know the Hbm* classes are generated from the schema and will
> therefore be up to date. If somehow someone figures out how to refactor the
> nhibernate classbinder to work with hbm classes then there will be an
> extremely easy path to removing xml from the process altogether, but things
> will still be fine if this never occurs.
>
> The Hbm* classes are too raw and we can't extend them ourselves, so we need
> our own rich model that we have control over. It seems there are two ways to
> approach this: either the model wraps the Hbm* classes, and the Hbm object
> graph is built up as the mapping occurs, or the model stores everything
> itself and then -generates- the Hbm object graph when it comes time to
> output the xml. I suspect the former will prove to be a more practical
> approach because we can simply expose the Hbm graph as a "get out of jail
> free" card much like we do with SetAttribute today.
>
> The fluent interface exists and looks much as it does today, and is
> implemented as a fluent builder on top of the rich model.
>
> Is this basically what you were thinking of Chad? Or is this over
> architected (something I am often guilty of)?
>
> At the risk of repeating myself, here are my justificiations for this
> proposal:
>

>    - It sucks when we have to tell people to hack on our code base or write

>    xml when they ask about lesser known features of the nhibernate schema. How
>    about the motto: "If NHibernate supports it, so do we".

>    - Writing code to generate xml sucks. Working against an object graph

>    that can be validated as you go and serialized to xml is nicer.

>    - Its hard to reason about the capability of a library when only a fluent

>    interface is exposed. All that nested lambda goo makes for nice calling code
>    but comes with a cost when it comes to extending the library.
>
> Thoughts?
>
> Paul Batum
>

[Fabio Maulo]

On 19 nov, 11:16, "Chad Myers" <c...@chadmyers.com> wrote:
> Fabio,

>
> Thank you for investigating this matter and explaining the current situation!

Investigating ? what do you mean ?
I'm inside NH-code-base from long time.. and NOT as maintainer (as you
said here and in the NH-dev-list).
I know the situation of that code during his development but change it
was not, and is not, my priority in NH.

[Chad Myers]

Fabio,

Please do not be so defensive!

RE: Investigating: Taking time to think about it, even if you knew this information off the top of your head. You graciously took time to share with us some information and clarify matters.

RE: Maintainer: Perhaps this word means something different to you. It is common to call someone who is actively working and supporting a project a "maintainer" similar to how someone who runs an Art Exhibit or Museum is called a "Curator."

The word "maintainer" is not an insult or a negative at all. It simply means "Someone who is actively participating in keeping the NHibernate project running" -- this means both NEW code and supporting the OLD code.

Ayende is the "maintainer" of Rhino Mocks, Jeremy is the "maintainer" of StructureMap, etc.

-Chad

________________________________

From: fluent-n...@googlegroups.com on behalf of Fabio Maulo
Sent: Wed 11/19/2008 5:04 PM
To: Fluent NHibernate
Subject: [fluent-nhib] Re: My discomfort with the current API

[Fabio Maulo]

I prefer: developers.

On 19 nov, 20:50, "Chad Myers" <c...@chadmyers.com> wrote:
> Fabio,
>
> Please do not be so defensive!
>
> RE: Investigating: Taking time to think about it, even if you knew this information off the top of your head.  You graciously took time to share with us some information and clarify matters.
>
> RE: Maintainer: Perhaps this word means something different to you. It is common to call someone who is actively working and supporting a project a "maintainer" similar to how someone who runs an Art Exhibit or Museum is called a "Curator."
>
> The word "maintainer" is not an insult or a negative at all. It simply means "Someone who is actively participating in keeping the NHibernate project running" -- this means both NEW code and supporting the OLD code.
>
> Ayende is the "maintainer" of Rhino Mocks, Jeremy is the "maintainer" of StructureMap, etc.
>
> -Chad
>
> ________________________________
>
> From: fluent-n...@googlegroups.com on behalf of Fabio Maulo
> Sent: Wed 11/19/2008 5:04 PM
> To: Fluent NHibernate
> Subject: [fluent-nhib] Re: My discomfort with the current API
>
> On 19 nov, 11:16, "Chad Myers" <c...@chadmyers.com> wrote:
>
> > Fabio,
>
> > Thank you for investigating this matter and explaining the current situation!
>
> Investigating ? what do you mean ?
> I'm inside NH-code-base from long time.. and NOT as maintainer (as you
> said here and in the NH-dev-list).
> I know the situation of that code during his development but change it
> was not, and is not, my priority in NH.
>

>  winmail.dat
> 6 KVerDescargar