First I want to say that I love this rewrite. Convention over
configuration always wins in my opinion, as long as the conventions
follow sensible defaults and best practices, which seems to be the
case.
Second I'd like to agree with Nick in that FNH serves its users best
when it mirrors how the programmer thinks when he designs his objects
and not how he would think if he was going to map the same object with
HBM XML. Renaming "index" to "key" and "element" to "value" makes a
lot of sense in that case. The same goes with renaming "key" to
"ForeignKey".
I haven't poked around with the code yet, but I have one question;
since the new dictionary mapping infers a lot more than previously,
how does it now handle custom collection implementations? Is that left
up to NHibernate to eventually blow up on if not configured right or
will FNH warn about it? And how would you set up a custom collection
implementation -- the same way as with HasMany?
-Asbjørn
On 4 Aug, 17:05, Nick Webb <nwe...@gmail.com> wrote:
> Fluent NHibernate is, after all, a big facade of NHibernate's xml mappings,
> no? Being a facade, I would not concern myself with how literal the fluent
> methods resemble the hbm context, as you said it yourself: you aren't
> necessarily looking to recreate the xml in c#. Instead, I'd follow a
> philosophy of how the methods best represent how the object property is
> being mapped. That's my opinion, anyway.
>
> So you're example of Index -> Key and Element -> Value seems very
> appropriate, especially for those not interested in learning how to rebuild
> an hbm map the 'fluent' way.
>
> To continue this approach:
> Index = Key
> Element = Value
> Key = ForeignKey
>
> My $0.02.
> - nick
>
> On Wed, Aug 4, 2010 at 6:18 AM, James Gregory <jagregory....@gmail.com>wrote:
>
>
>
> > It's a hard one, and something that thoroughly annoys me about nhibernate
> > maps. They're consistent with the other collections in naming, but the
> > element behaviour/intent is different.
>
> > <map> : Dictionary
> > <key> : Foreign key
> > <index> : Dictionary.Key
> > <element> : Dictionary.Value
>
> > I'd like to rename Index to Key and Element to Value, but I think that
> > might be too different (and Key could then be confused for the <key>
> > element).
>
> > I'm open to suggestions though.
>
> > On 4 Aug 2010, at 10:48, Rasmoo <ras...@gmail.com> wrote:
>
> > > It looks really nice and accessible. One minor nitpick though:
>
> > > When writing the hbm.xml files, it's fairly obvious when index is a
> > > collection index, and when it's a database index. However, I might now
> > > write:
>
> > > Map(x => x.Name)
> > > .Index("IX_SomeTable_Name");
> > > HasMany(x => x.Comments)
> > > .Index("Author");
>
> > > Which causes me (and maybe just me) some cognitive dissonance. I know
> > > it does not match the NHibernate vocabulary, but perhaps something
> > > like CollectionIndex or IndexColumn would create the right
> > > association?
>
> > > On Aug 2, 11:07 pm, James Gregory <jagregory....@gmail.com> wrote:
> > >> Hello everyone,
>
> > >> I've been working on something that I've been promising to do for a long
> > >> time, rewrite our <map>/IDictionary functionality. It's not a shiny new
> > >> feature or anything like that, but it's a nasty area of our user
> > interface
> > >> and codebase as a whole that has needed redoing for a long time.
>
> > >> I've put a branch up on the github repository with the work so far. This
> > is
> > >> very much a work in progress, and several things are unimplemented (most
> > >> attributes, for example) but the general structure is present. I'd
> > >> appreciate it if anyone who has some spare time would take a look,
> > >> especially people who've had problems with <map>/IDictionary's in the
> > past.
>
> > >> Branch:http://github.com/jagregory/fluent-nhibernate/tree/map-refactor
>
> > >> The refactoring is based on the following principal: infer or assume as
> > much
> > >> as possible, while providing a way for the user to customise as much as
> > >> needed.
>
> > >> The HasMany and HasManyToMany dictionary overloads now return a new
> > builder
> > >> instance, instead of the general collection builder as before. This new
> > >> builder is tailored specifically to dictionary mappings, and thus is
> > much
> > >> more specialised (and simpler in implementation). This is also why
> > several
> > >> features are currently unavailable, because they need to be
> > reimplemented in
> > >> the new builder (I'm deliberately keeping the classes separate, to avoid
> > the
> > >> mess we have currently).
>
> > >> Indirectly due to these changes, the following methods have been
> > deprecated
> > >> and/or removed entirely:
>
> > >> - AsMap
> > >> - AsEntityMap
> > >> - AsTernaryAssociation
> > >> - AsSimpleAssocation
> > >> - ParentKeyColumn (now just Key())
>
> > >> The mappings that all those methods created are entirely doable using
> > the
> > >> new interface. When these changes get merged into master, removed
> > methods
> > >> may be reintroduced and marked as obsolete rather than being removed
> > >> entirely.
>
> > >> *A few examples:*
>
> > >> HasMany(x => x.Comments);
>
> > >> Where Comments is an IDictionary<string, string> would create a <map>
> > with
> > >> an <element>, with Key and Value as the column names.
>
> > >> HasMany(x => x.Comments)
> > >> .Element("Content");
>
> > >> Same as above, except with the element column overridden.
>
> > >> HasMany(x => x.Comments)
> > >> .Index("Author");
>
> > >> Same as above, except the index (dictionary key) column is overridden.
>
> > >> There's similar overloads for CompositeIndex, CompositeElement,
> > OneToMany,
> > >> and ManyToMany. Each method has a couple of simplistic signatures
> > (string
> > >> for column name, generic type for column type) and a lambda-based
> > signature
> > >> for advanced configuration.
>
> > >> HasMany(x => x.Comments)
> > >> .Index(ix =>
> > >> {
> > >> ix.AsManyToMany();
> > >> ix.Column("one");
> > >> ix.Column("two");
> > >> ix.ForeignKey("FK_something");
> > >> });
>
> > >> You get the idea.
>
> > >> Feedback is much appreciated, and none of this is set in stone (or
> > complete)
> > >> yet.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Fluent NHibernate" group.
> > > To post to this group, send email to fluent-nhibern...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > fluent-nhibernate+unsubscr...@googlegroups.com<fluent-nhibernate%2bunsubscr...@googlegroups.com>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/fluent-nhibernate?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Fluent NHibernate" group.
> > To post to this group, send email to fluent-nhibern...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > fluent-nhibernate+unsubscr...@googlegroups.com<fluent-nhibernate%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/fluent-nhibernate?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibern...@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.
