Yo It's good to see you've all caught up with me ;o), by the way automap can do most of this already (disclaimer: there are bits missing)
I'm all for this - Chad has hit it on the button, basically we need cleaner convention support, and to make automap talk to a semantic model rather than the fluent api, which is an absolute nightmare to work ontop of. However the fluent api is great for customising those instances where you go against the convention, so we should definetly keep it, it just needs re-engineering over a semantic model rather than the xml. The question is how do we move the re-engineer what we've got without doing a massive rewrite which I think would be bad idea. Cheers Andy On Mon, Jan 12, 2009 at 7:41 PM, Jeremy D. Miller <jeremydmil...@yahoo.com>wrote: > It's definitely going to be nice to do the one-offs as something like: > > Customize(Action<SemanticModel>) > > instead of having to translate everything to the Xml > > Jeremy D. Miller > The Shade Tree Developer <http://codebetter.com/blogs/jeremy.miller> > jeremydmil...@yahoo.com > > > ------------------------------ > *From:* Chad Myers <c...@chadmyers.com> > *To:* fluent-nhibernate@googlegroups.com > *Sent:* Monday, January 12, 2009 1:38:45 PM > *Subject:* [fluent-nhib] Re: Rethinking Fluent NHibernate > > We're mostly there, we have the starts of it, but AutoMap was build on top > of the Fluent API which has hampered it. > > First, we need the semantic model. Paul Batum said he'd have this done by > the end of the week ;) j/k. We've kicked around ideas, this just needs a > champion to get the ball rolling. > > Second, we get really serious about conventions. To the maximum extent > possible, all decisions and opinions become conventional. > > Third, we'd need to take the existing automapping discovery code and use it > and possibly enhance it wherever it needs enhancement > > Fourth, we expose the config directly and/or have an internal DSL for > making the one-off overrides and/or "more complex conventions" that depend > on multiple conditions being met for them to be applied, etc > > -c > > > > ________________________________ > > From: fluent-nhibernate@googlegroups.com on behalf of Chad Myers > Sent: Mon 1/12/2009 1:36 PM > To: fluent-nhibernate@googlegroups.com > Subject: [fluent-nhib] Rethinking Fluent NHibernate > > > [Credit to Aaron Jensen for giving some great feedback and sending me down > this thought path, and numerous others who have complained about lack of > private/protected member support and for committers/contributors who've been > kicking around ideas and forging ahead with new ideas] > > What if we took the convention stuff all the way to 11? > > What if you could point FNH at your assembl(y|ies) and give it some > criteria (i.e. everything in namespace FOO, that derives from type > BaseEntity, etc) and it would discover all your entities that need mapped? > > What if FNH would discover all the public properties and public/private > fields and could make reasonable guesses about how those should be mapped? > > What if you could guide it conventionally to figure out how to map the > tricky parts? > > Lasty, for very complex things, you could dip down to specifics. > > I'm imaginging something like: > > Dear Fluent NHibernate: > > Please discover all my entities which are located in my "Core" assembly, in > all namespaces under the namespace ending with "Domain", and which derive > from my BaseEntity class. > > You should know: > * All my entities have an "Id" property and should be mapped using the > hi/lo + guid.comb generators > * All my table names are the pluralized form of the entities names > preceeded with "t_" > * All my foreign key names start with "fk_" > * All my many-to-many join tables have the format "mtm_A_B" where A and B > are the pluralized form of the entity names > * (etc, etc, etc) > > Also, if you come across an apparent relationship between Contact and Site, > map it as a OTM to an intermediate table (using entity ContactSiteRole) and > then an MTO to the other side (blah blah blah) > > If you come across a relationship involving EntityA and EntityB, map it > like this... > > By the way, I'd like you to make all OTM's "Cascade All" except for > relationships involving EntityF and EntityQ. > > (and so forth) > > -c > > > > > > > > > > -- ================= I-nnovate Software - Bespoke Software Development, uk wirral. http://www.i-nnovate.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to fluent-nhibernate@googlegroups.com To unsubscribe from this group, send email to fluent-nhibernate+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
