Agree on all counts; sounds like you have already thought through much of what I was mentioning. Just trying to ensure that we're thinking about all the impacts before making the proposed change(s) :D
It seems to me that the suggested approaches for mapping POID have all the bases covered well (via strings for the private fieldname, etc.). In FNH this was accomplished with a Reveal.Property<T>(...) method ( http://wiki.fluentnhibernate.org/Fluent_mapping_private_properties lays out their provided choices). That wiki entry does a great job of laying out the pros and cons of the various approaches and I was wondering if your thoughts were more along those lines (reflection helper class) or the string-literal approach. re: NH and Hb 'correlation', I completely agree w your observation here: some divergence cannot be avoided and other divergence is in NH's best interests to improve the project for .NET (and this proposed API is perhaps one of those 'valuable' divergences!). Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Jan 18, 2010 at 11:20 AM, Fabio Maulo <[email protected]> wrote: > Some of XML "statements" are actually supported by our configuration > through metadata directly instead a mapping API. > The first implemented was exactly for <database-object>: > conf.AddAuxiliaryDatabaseObject(IAuxiliaryDatabaseObject obj) > > btw I think we will include everything in the API: > map.DatabaseObject.... > map.TypeDef > map.FilterDef > and so on. > > About private fields and access="none" and "columnName": in these cases I > don't think we having any kind of alternative than use a string. > > On the other end, for the <id> for example, in NH you may have neither a > property nor a field. The possible overload are: > > Class with public POID property getter > void Class<TEntity>(Expression<Func<TEntity, object>> idProperty, > Action<IIdMapper> idMapping, Action<IClassMapper<TEntity>> classMapping) > where TEntity : class; > > Class with private POID field: > void Class<TEntity>(string idFieldName, Action<IIdMapper> idMapping, > Action<IClassMapper<TEntity>> classMapping) where TEntity : class; > > Class with neither a property nor a field > void Class<TEntity, TPoid>(Action<IIdMapper> > idMapping, Action<IClassMapper<TEntity>> classMapping) where TEntity : > class; > (note: in this last case the TPoid is enough to create the mapping). > > About NH and Hb: > "Stay closer" does not mean "do the same or less", we can do something more > because we are using .NET and, at the same time, in some cases we must do > less because we are using .NET. > I don't think we will have something like Hibernate.Annotation nor > Hibernate.EntityManager. In Hibernate they are thinking in their ecosystem > and, unfortunately, without any kind of communication with us (this is not > the same of Spring.NET). > The "mapping source" is only a little detail in NH-Core, what is important > is that we are supporting same mappings features or more (and believe me we > are supporting more mappings-features in various cases). > > 2010/1/18 Stephen Bohlen <[email protected]> > > First, some quick impressions: >> >> - Its conceptually nice to relegate XML mapping to a less-central role >> within NH (e.g., XML now becomes just ONE of MANY possible 'mapping input >> syntax forms') so I applaud the effort/intent >> - Decoupling mapping + config from XML entirely will definitely >> support many more alternate declarative inputs (custom DSL, whatever) in a >> manner much more flexible than having to depend on XML as an 'intermediate >> translation layer' for NH to consume mapping/config info >> - I like that the thrust of the syntax more closely parallels the >> nodes/attributes used in the XML files, making it approachable to existing >> users of XML mapping files (reasonably shallow learning curve) even as >> this >> leads to a fairly verbose API (compared let's say, to something like FNH >> where 'terse API' was --from my reading-- an implicit design goal) >> >> Next, some more specific feedback/issues/thoughts/concerns we might want >> to consider (in no particular order): >> >> - If this API is to become 'authoritative' for mapping, then by >> extension it clearly needs to completely support all existing 'xml >> constructs' fully >> - Unlike FNH where the authors have taken the entirely valid approach >> of "we're releasing with support for the 80% of NH mapping constructs that >> are most-commonly in use, permitting people to weave in xml-based content >> for the parts we don't yet support in code, and over time we will evolve >> to >> support the remaining 20% edge-cases in the fluent API", IMO for NH this >> API >> shouldn't be released into the codebase until it has 100% functional >> equivalency with each and every existing XML construct and doesn't rely on >> intermingling xml for any of its needs. >> - Obviously as an existing proof-of-concept this isn't yet done but it >> would seem important before making this the authoritative API to ensure >> that >> adequate spikes are done to be certain that for every 'statement' >> presently >> possible in XML, there's at least an idea about how to express that in >> this >> new API (some of the edge-cases that come to my mind initially are things >> like the <database-object> elements, stored procedures, filter statements, >> where statements, etc. that aren't immediately obvious from the sample >> code >> in the blog post re: how they would be addressed -- basically the entire >> category of things presently definable in XML that aren't necessarily >> *directly* about mapping entities per-se but that are about caching >> directives, other DB elements, etc.) >> - We need to ensure that adequate consideration is given to how this >> API would express things that aren't immediately possible to state as >> lambda's without some 'tricks' via reflection, etc. For example, this >> kind >> of statement from the sample code... >> >> map.Class<Animal, long>(animal => animal.Id, id => id.Generator = >> Generators.Native, rc => >> >> ...won't work where the POID is actually not a public property of the >> Animal class but is instead a private field and of course the statement >> (animal => animal._persistentId, ... won't compile b/c the private field >> _persistentId is not visible to intellisense (or more importantly, the >> compiler!). To be sure, there are 'tricks' to get around this lambda >> limitation, but I recommend that we should consider carefully what this will >> look like when invoked via this API to be sure its as clear as the >> public-property-based mappings shown in the sample code. >> >> - How does moving this fluent-API into the role of 'primary' mapping >> API affect NH's 'parity' with Hibernate? Is it possible that Hibernate >> might get a future feature that would want to be ported to NH but we would >> find that this (hypothetical) new feature isn't expressible in the new >> fluent API? Obviously nobody can predict the future, but the move to this >> API as 'primary' mapping API would seem to represent a digression from >> NH's >> close parity with H which may impact the ease with which future features >> can >> be ported from H to NH. This new fluent API might very well be a >> useful/valuable digression (and obviously there are already OTHER features >> that have been added to NH that take advantage of the .NET platform and >> don't have an allegory in Hibernate so diverting from exact parity with H >> isn't without precedent), but IMO we should carefully consider its >> potential >> future impact on porting H features to NH before we decide to 'deprecate' >> XML as the primary/core mapping API. >> >> In short: I like the approach, think it will be quite valuable and helpful >> to anyone trying to write inputs to the NH mapping/config API in the future, >> but recommend that we consider the above issues/thoughts before introducing >> this API as a 'replacement' for the primacy of the xml API in the project. >> >> HTH, >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> >> On Sun, Jan 17, 2010 at 5:40 PM, Fabio Maulo <[email protected]>wrote: >> >>> Please, I'm needing feed-back coming from code-review. >>> >>> Try to think at it as a possible mapping-by-code solution for NH3.0. >>> I'm seriously thinking to add it in NH directly. >>> >>> 2010/1/13 Fabio Maulo <[email protected]> >>> >>>> Hi team. >>>> >>>> I would like to have a code re-view of my last post and >>>> a constructive feedback >>>> >>>> http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.html >>>> >>>> >>>> <http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.html>The >>>> post, and overall the code, is basically an example about how implement a >>>> custom API to create mappings by code. >>>> That is an invitation to everybody want create his own API and even an >>>> invitation for FNH team to use the Hbm* classes instead generate XML. >>>> >>>> That said, seeing how things are going in each framework, NH needs its >>>> own mapping-by-code. >>>> Two matters here: >>>> 1) API definition >>>> 2) usage of Hbm* or directly create metadata (classes of namespace >>>> NHibernate.Mapping) >>>> >>>> What is clear is that our implementation will supports anything >>>> supported by XML and, probably, we will improve some of actual >>>> "conventions-interceptors" (as, for instance, INamingStrategy & Co. ). >>>> >>>> -- >>>> Fabio Maulo >>>> >>>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> > > > -- > Fabio Maulo > >
