New project for mappings

[Fabio Maulo]

Hi all.

I'm going to begin a new project for programmatic configuration of class mappings.

My intention is not support legacy DB that mean not support a lot of actual XML mapping.

I would like to know your opinion about which should be the place of such kind of project.

Inside NH-Core or Outside ?

Vote for committers are: Inside/Outside

Users's opinions are welcome but not sum as committer's vote.

Thanks.
--
Fabio Maulo

[Michael Teper]

Fabio, how will this be different from FluentNH?

 

Thanks!

-Michael

[Tuna Toksoz]

Inside. 

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Fabio Maulo]

2009/7/10 Michael Teper <michae...@elanex.biz>

Fabio, how will this be different from FluentNH?

I don't want make comparison. btw a difference is that the new prj does "not support legacy DB", another is that does not generate XML.... ..... ...... ...... ......

Somebody ask me to "land" the ORuM propositions... well... the new prj will be a landing of ORuM.

--
Fabio Maulo

[Stephen Bohlen]

If we think this to be a feature of NH 3.0 (and I hope so) then I vote 'inside'.  If we aren't certain it will be releasable by NH 3.0 then I vote 'outside' and leave it in NH-Contrib for now.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Fabio Maulo]

I'm thinking about which will be the place "outside" because, in that case, configure NH will be only an option.

2009/7/10 Stephen Bohlen <sbo...@gmail.com>

--
Fabio Maulo

[Tuna Toksoz]

But it is not "yet-another-configuration". It deserves to be a part of the core.

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Fabio Maulo]

Michael I have a question for you.

I saw you asking the same question for the Loquacious configuration.

Is your question a praxis ?

2009/7/10 Michael Teper <michae...@elanex.biz>

--
Fabio Maulo

[Michael Teper]

Fabio, I had to look up the definition of "praxis" and I am still not clear what you asking? :)

 

But yes, I was confused about the difference between FluentNH and Loquacious config, though I later figured out that one was about configuring the mappings and the other was about configuring NH (true?). If I was right in my understanding, your latest proposal seems redundant again ("new project for programmatic configuration of class mappings").

 

I am just trying to keep up with the rapidly evolving landscape. :)

 

Thanks!

-Michael

 

 

---

From: nhibernate-...@googlegroups.com [nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo [fabio...@gmail.com]
Sent: Friday, July 10, 2009 5:00 PM
To: nhibernate-...@googlegroups.com
Subject: [nhibernate-development] Re: New project for mappings

[Michael Teper]

Forgive me for being slow. I get the benefits of "does not generate XML" -- I didn't realize Fluent NH was an XML generator -- but what does dropping legacy DB support mean?

 

Thanks!!

-Michael

 

 

---

From: nhibernate-...@googlegroups.com [nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo [fabio...@gmail.com]
Sent: Friday, July 10, 2009 4:13 PM
To: nhibernate-...@googlegroups.com

Subject: [nhibernate-development] Re: New project for mappings

[James Gregory]

So it'll do less than FNH, but not generate xml? What happens when FNH stops generating xml too, then what?

[Davy Brion]

I'd vote for inside, but i would like to hear more about the purpose and the goals of this new project

[Graham Bunce]

What benefit is this if FluentNH already does something similar?

Can't Fluent NH (that people are starting to use and understand) be
retro-fitted to not generate the mappings and be brought into NH core
(like Lamda critera has been)

[Stephen Bohlen]

The mechanism that FNH uses to permit you to define the mappings is to (behnd the scenes) generate XML and feed that to NH's configuration at run-time.  NH 2.x and earlier offered no real extension points for mapping declarations and so esentially 'any way that you can create XML and feed it to NH would work' and this is what FNH presently does to achieve its results.  Its fundamentally the same thing that various code-generators have done with NH for years, but in this case the 'code-gen template' is .NET code and it happens at run-time instead of at compile-time.

 

Because of this approach, FNH's constructs, syntax, API, etc. are tightly coupled to the specific and exact mapping constructs that can presently be declared in the XML 'by hand' (or any other way one might choose to create XML).  Essentially, FNH is a giant XML generator that knows the structure of the XML that NH expects.  Even when FNH becomes 'feature complete', it would support a 1:1 relationship between itsself and the XML syntax presently supported by NH (note that I don't mean a 1:1 relationship between API calls and XML syntax per se, of course).  But FNH isn't able to provide more powerful mapping concepts than that supported by the present NH XML syntax because in the end no matter what's done insie FNH to make its API more powerful/useful/convention-based, etc. the chain still HAS TO look like...

 

     FNH --> XML --> NH (note the intermediate XML here)

 

The goal of the new mapping-in-code efforts for NH is to achieve this...

 

     [declarations-in-code] --> NH (note, no intermediate XML representation is involved here)

 

Because of this, there won't be a 1:1 relationship between mappings that can be expressed in the XML and 'object relations' that can be expressed in the new 'declarations-in-code' approach.

 

Its extremely likley that the existing API for FNH (which is really designed around providing an API for producing the XML NH currently expects) won't be appropriate/sufficient to model these new 'object relations' in code and so to a large degree existing 'familiarity' with the FNH API is unlikley to be relevant to this new approach since the API will almost certainly have a very different 'shape' because its not designed around providing 'exactly enough information to spit out the XML that NH expects'.

 

While its certainly possible (and likely) that aspects of what FNH currently achieves will be present in this new approach, when completed its unlikley that they two would have significant similarity of API, behavior, syntax, etc. beyond 'both being expressed in code'.

 

Note that this is a) all just my opinions and b) VERY early in the conceptual phases of this effort so any and all of what I've said here may be either now or in the future completely wrong but I hope this clarifies a little more about the pholisophical and technical differences between this proposed effort and FNH.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Rei]

So basically we will end up having access to what ever takes xml files
and creates the mappings so we can create the mapping directly in
code. Me thinks sexy :) Inside.

> sboh...@gmail.comhttp://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen

[Fabio Maulo]

2009/7/11 Graham Bunce <graha...@hotmail.com>

What benefit is this if FluentNH already does something similar?

Before somebody else continue with the same question I would like to have an answer to these questions:

Which is the benefit/differences between:

Win7, MacOsX, Umbutu... ?

NUnit, MbUnit, xUnit ?

Spring.Net, Castle.Windsor, LinFu, AutoFact, Unity, StructureMap, Funq ?

MsSQL, Oracle, MySql, PostGres, FireBird, SqLite.... ?

Log4Net, NLog, EL-Logging ?

LinFu-AOP, Castle-AOP, Spring-AOP, PostSharp, Cecil ?

J#, C#, VB.NET, Delphi.NET, IronRuby, IronPython ?

When somebody will explain me, in detail, why we should have so many options to do the same I will explain why I want start a different project.

--
Fabio Maulo

[Fabio Maulo]

2009/7/11 Graham Bunce <graha...@hotmail.com>

Can't Fluent NH (that people are starting to use and understand) be
retro-fitted to not generate the mappings and be brought into NH core
(like Lamda critera has been)

This is another matter...

FNH first commit : 2008/7/24

Date of the post : 2008/11/12 (November)

http://fabiomaulo.blogspot.com/2008/11/mapping-source-how-map-class-without.html

Since NH2.0.0 the ability to create mappings without create XMLs is there and the FNH was informed and was invited to come with us. If I well remember, Chad Mayer said that NH need a lot of modification to be configured without XML and Ayende ask him (in FNH list) a patch. We never saw the patch nor proposal. FNH can change his way to work just now.

--
Fabio Maulo

[Fabio Maulo]

2009/7/11 James Gregory <jagregory.com@gmail.com>

So it'll do less than FNH, but not generate xml? What happens when FNH stops generating xml too, then what?

Because the new project probably will do less than NH's XML mapping I'm asking to the NH's team which should be the place of the new project.

I'm the project lead here but rules are rules even for the PL.

--
Fabio Maulo

[Chris Constantin]

Inside

On Sat, Jul 11, 2009 at 6:38 AM, Fabio Maulo<fabio...@gmail.com> wrote:
> 2009/7/11 James Gregory <jagreg...@gmail.com>

[James Gregory]

Stephen, I believe you should do some more research before making sweeping statements like you have. FNH has been refactored so there is an intermediary layer between the fluent interface and the xml generation, which essentially allows us any amount of flexibility before finally passing to NH. The portion that generates XML will be depreciated in the coming weeks and replaced with a HBM class generator.

As far as I'm concerned FNH is not just a fluent XML dialect, it will not be 1:1 to the xml.

I do not think this is a valuable use of people's time, but it's not my time you're using. You obviously do not need or want the blessing of the FNH team on this.

[James Gregory]

Fabio, please refer back to our previous conversations on this matter. FNH declined to provide a patch because no assurances were given that such a patch would even be considered by the rest of the team (yourself and Ayende aside). We deemed that the effort would be better spent in our own codebase where we were gaurenteed to be able to use it.

[Germán Schuager]

It could be started outside and once that the scope and intention is more clear decide whether to move it to the core or not.

Anyway, from what I've heard about ORuM I'm looking forward to this.

[Fabio Maulo]

2009/7/11 Germán Schuager <gsch...@gmail.com>

It could be started outside and once that the scope and intention is more clear decide whether to move it to the core or not.

Anyway, from what I've heard about ORuM I'm looking forward to this.

But the prj will be not ORuM. To be ORuM it need some AI concepts and probably a lot of time to implements it.

--
Fabio Maulo

[Stephen Bohlen]

James:

 

I apologize if my info is out of date; admittedly its based on the (much) earlier instances of FNH with which I was familiar and I have not reviewed recent releases of the project.  If my info is incorrect/superceded then I'm definitely sorry if I've spoke based on outdated information -- its certainly not my intent to communicate from a position of ignorance and if that has been the case then I entirely apologize.

 

Re: FNH being a fluent XML dialect, what I was trying (and may have failed miserably) to get across is that AFAIK FNH is attempting to express in code the same relationships, settings, values, etc. that are expressed in the XML files and so conceptually the 'problem' it tries to solve is offering another way to express the same content as would also be possible to express in the XML files.  While FNH offers the benefit of things like more concise/less verbose statements of intent via conventions, defaults, etc.,at the end its another representation of the same concepts that exist in the XML mapping files (even if its only output 'format' for communicating this to NH isn't solely XML any longer).

 

As Fabio has mentioned prior, this new project isn't about finding another way to express all of the same 'concepts' as the XML presently offers and so while there is certainly some (expected) overlap in general capability with FNH, my own personal opinion is that the two projects would (future) probably still need to coexist as neither is really a superset of the functionality of the other.

 

When we say "many aspects of legacy databases wouldn't be supported by this new approach to mapping" I think we're implicitly suggesting that the scope of what's presently describable in either FNH or XML (or anything else) is fundamentally different than this project is proposing to support.  As such, it seems to me that there would certainly be a need moving forward for the two 'scopes of capability' to co-exist and users would simply take advantage of whichever one properly met their needs.  In short, I don't (personally, speaking for myself) see this as being an either-or type choice -- there is reasonable need for all of these movng forward.

 

My attempt was to try to clarify 'intent' of the projects in order to try to help clarify the differences between their 'goals' in response to some questions about how this differs from FNH and I'm sorry if in the process I managed to refer to implementation details with which I'm no longer current in my knowledge of -- no harm intended on my part there and I'm sorry if it came off that way.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Steve Wagner]

I would vote for inside because then i would expect that it is more in
sync with the NH Trunk then Fluent currently is.

And i hope that it will not have the main disadvantages i see in Fluent
today. First that naming is not consistent with the XML Mapping, this
makes it harder to transform all the xml mappings in blog posts and
documentation to code syntax. And second that fluent has a lot of
methods where it is not clear what they are for (when i only have
intellisens) or method which are only used for internal processing and
not used for mapping.

Fabio Maulo schrieb:
> Hi all.I'm going to begin a new project for programmatic configuration of

[James Gregory]

Stephen: Your information is out of date; however, you are correct that we are taking the same "view" on the mappings as the XML is. I think you've understated our capabilities and purpose. XML is only our output format, we can conceptually do anything before the final generation stage.

I think the problem most of us are having here is there is very little evidence of what's actually being proposed. It's fluent mappings, but it's not like FNH, but it's not ORuM, and it's not for legacy DBs, and it's a new perspective on the model; these are vague and slightly conflicting. Surely people have to understand what it is before you can ask where it should live?

Steve Wagner: We can't improve Fluent if you don't actually tell us about your issues it. Being part of a silent minority/majority isn't very useful. You've made some good points, but yet they've never made their way to our ears outside of this conversation. Though as already stated, FNH is not a fluent-XML dialect, we have no desire to mimic the XML.

[Fabio Maulo]

For sync... inside or outside is not a matter

NHV, NHCH, uNhAddIns are outside but all are in sync with the last release of NH (last release or coming release).

2009/7/11 Steve Wagner <li...@lanwin.de>

--
Fabio Maulo

[Steve Wagner]

James Gregory schrieb:
> *Steve Wagner:* We can't improve Fluent if you don't actually *tell us* about

> your issues it. Being part of a silent minority/majority isn't very useful.
> You've made some good points, but yet they've never made their way to our

> ears outside of this conversation. Though as already stated, FNH is *not* a

> fluent-XML dialect, we have no desire to mimic the XML.

They did on Oct 21, 2008

http://code.google.com/p/fluent-nhibernate/issues/detail?id=60&can=1

;-)

[Fabio Maulo]

2009/7/11 James Gregory <jagregory.com@gmail.com>

I think the problem most of us are having here is there is very little evidence of what's actually being proposed. It's fluent mappings, but it's not like FNH, but it's not ORuM, and it's not for legacy DBs, and it's a new perspective on the model; these are vague and slightly conflicting. Surely people have to understand what it is before you can ask where it should live?

NH's committers, apparently, does not have problems to define where it should stay.

Btw don't worry...

Taking Steve's (B.) and Davy's thoughts/preocupations I'm thinking in put it outside the core; when the moment become, if the integration is desired, should be only a matter of R# namespace renaming.

--
Fabio Maulo

I prefer to try something good and fail, than to try something wrong and achieve it

[Michael Teper]

Fabio, the point is not whether one can justify the existence of all members of a given set, the point, of course, is whether each member can justify its own existence. The question I raised, that has been picked up by a few other people, essentially boils down to a request for more info. We are not saying you have a bad idea that you should not pursue, we are just asking for a bit of clarification on what the idea is.

 

In other words, we are not (or at least I am not) attacking you -- I am asking for your help and clarification!

 

Thank you!  :)

-Michael

 

 

---

From: nhibernate-...@googlegroups.com [nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo [fabio...@gmail.com]

Sent: Saturday, July 11, 2009 6:11 AM

To: nhibernate-...@googlegroups.com
Subject: [nhibernate-development] Re: New project for mappings

[Fabio Maulo]

I never feel an attack. Ask for comparison before start a new prj is something long to do and I'm writing a better C# than a good English and, btw, lot of prjs have a very similar purpose but each prj implements a different point of view.

2009/7/11 Michael Teper <michae...@elanex.biz>

--
Fabio Maulo

[James Gregory]

I think a lot of us are better at expressing our thoughts, and understanding others, when it's in code :)

[Paul Batum]

Hi Stephen,

Can you give me an example of the sort of new "object relation" that
you are referring to? When I consider the future of NH mapping, I see
something that is mostly automated by conventions and smart inspection
of the model that is being mapped, with sufficient control to allow
users to deal with special cases when they arise. It sounds like you
can see some possibilities that are different from this, and I would
like to get a more concrete understanding of what these might be.

Thanks!

Paul Batum

On Jul 12, 12:47 am, Germán Schuager <gschua...@gmail.com> wrote:
> It could be started outside and once that the scope and intention is more
> clear decide whether to move it to the core or not.
>
> Anyway, from what I've heard about ORuM I'm looking forward to this.
>

> On Fri, Jul 10, 2009 at 8:01 PM, Fabio Maulo <fabioma...@gmail.com> wrote:
> > Hi all.I'm going to begin a new project for programmatic configuration of

[Mark Nijhof]

Hi Fabio,

Just an opinion from a bystander: Why not do a joint effort together
with the Fluent NHibernate team? They already have a lot of work done,
the only thing missing is that they cannot talk directly with the
NHibernate core. Opening this up for them / with them would probably
be welcomed with open arms from their side as well?

-Mark

[Fabio Maulo]

Why "cannot talk" ? all classes are there and are public, every one can use it (see mail above).

2009/7/11 Mark Nijhof <mark....@gmail.com>

--
Fabio Maulo

[Mark Nijhof]

Hi Fabio,

As I understood it from before that FNH was not able to "inject" the
NH configuration classes with how the code is now. But as I said :)
Innocent bystander that is just curious about why not joining efforts?
I have wondered before how long it would be until FNH became part of
NH as they complement each other :-)

-Mark

[Fabio Maulo]

2009/7/11 Mark Nijhof <mark....@gmail.com>

Innocent bystander that is just curious about why not joining efforts?
I have wondered before how long it would be until FNH became part of
NH as they complement each other :-)

Good question but believe me that is the wrong place where ask it, and I'm having to much white hairs to retake the discussion again.

--
Fabio Maulo

[Mark Nijhof]

hehe well I didn't know that, since you don't show a picture on your
twitter profile :P

-Mark

[Paul Batum]

Theoretically, FNH can talk directly to the mapping core. During the
early stages of my work on the FNH semantic model, Tuna was
experimenting with exactly this. He abandoned it before getting
particularly far. My impression (and its just an impression - I would
like to see Tuna's thoughts on the issue in this thread!) was that it
was difficult for an external system to work directly with the mapping
core primarily because of a lack of validation. The nice thing about
mapping NH with xml (which is what Castle.ActiveRecord and FNH do) is
that you get that validation.

I'd also like to point out that the xml mapping schema is recognised
as a public interface. As such the NH team does a great job of
minimizing the number of breaking changes made to the xml format. I do
not believe (and please correct me if I'm wrong!) that NH has any
other interface where the same level of care is taken regarding
breaking changes. And a public interface is exactly what we want to be
building FNH on top of - I would rather not have FNH breaking every
time NH's mapping *implementation* changes.

Paul Batum

[Richard Brown (gmail)]

Inside, if it means we could also use it inside the core tests for other functionality.

From: Fabio Maulo

Sent: Saturday, July 11, 2009 7:18 PM

To: nhibernate-...@googlegroups.com

Subject: [nhibernate-development] Re: New project for mappings

[Davy Brion]

ah, that is a good point... it could make writing testcases easier (both for us as well as people who report issues)

[Darius Damalakas]

My vote: outside

Reason - having read all the 40 emails, the thing that the new project
would achieve is remove the XML from the stage in configuring NH. But
it's not clear any other project goals. When the project gets more
mature, it could be of course included into NH-Core

Today we are using Castle.ActiveRecord to define our mappings, so the
only thing with XML that bothers is the speed that it takes to
configure NH, and this can be handled with pre-generating XML.

On Jul 12, 12:56 pm, Davy Brion <ral...@davybrion.com> wrote:
> ah, that is a good point... it could make writing testcases easier (both for
> us as well as people who report issues)
>
> On Sun, Jul 12, 2009 at 10:29 AM, Richard Brown (gmail) <
>

> fluke...@googlemail.com> wrote:
> >  Inside, if it means we could also use it inside the core tests for other
> > functionality.
>

> >  *From:* Fabio Maulo <fabioma...@gmail.com>
> > *Sent:* Saturday, July 11, 2009 7:18 PM
> > *To:* nhibernate-...@googlegroups.com
> > *Subject:* [nhibernate-development] Re: New project for mappings
>
> > 2009/7/11 James Gregory <jagregory.com@ <jagregory....@gmail.com>gmail.com

[Peter Smulovics]

My vote: outside...

[Dario Quintana]

Hi

My vote is: put it in whatever who is/are going port/implement think is the better option.
If the person/s in charge think is going to write less code putting it inside, then it's OK.
If the person/s in charge think is going to write less code putting it outside, then it's OK.

My reason: there are not many active commiters, and nobody has time to spare, if whatever the choise is, will make feel more confortable to the commiter, then go ahead.

Cheers.
--
Dario Quintana
http://darioquintana.com.ar

[Fabio Maulo]

End of the discussion...
The project is alive and is here
http://code.google.com/p/codeconform/
Are you ConfORM ?

LOL

2009/7/10 Fabio Maulo <fabio...@gmail.com>

Hi all.

I'm going to begin a new project for programmatic configuration of class mappings.

My intention is not support legacy DB that mean not support a lot of actual XML mapping.

I would like to know your opinion about which should be the place of such kind of project.

Inside NH-Core or Outside ?

Vote for committers are: Inside/Outside

Users's opinions are welcome but not sum as committer's vote.

Thanks.
--
Fabio Maulo

--
Fabio Maulo