To elaborate a little, I'm going to backport as many of the commits as I can to 
the v1.x branch and obsolete (with warnings) as much as possible. Probably not 
an optimal workflow... Meh

On 31 Aug 2010, at 01:33, Paul Batum <paul.ba...@gmail.com> wrote:

> Oops, nevermind, I see its already in there. Tally ho!
> 
> On Tue, Aug 31, 2010 at 10:29 AM, Paul Batum <paul.ba...@gmail.com> wrote:
> What are your plans from a versioning perspective? This is a pretty sizable 
> breaking change. Should we start maintaining a 2.0 branch? I'm just not sure 
> if pushing the changes directly into the current master is a good idea.
> 
> 
> On Mon, Aug 30, 2010 at 4:17 AM, James Gregory <jagregory....@gmail.com> 
> wrote:
> I've updated the branch with basic support for custom collections, it should 
> be able to infer a lot of the same stuff it can with regular collections; for 
> other cases, you'll need to specify it manually.
> 
> I've also just renamed the methods to be more inline with the conceptual 
> naming, rather than NHibernate specific.
> 
> So for anyone that's used this so far:
> 
> Key -> ForeignKey
> Index -> DictionaryKey
> Element -> DictionaryValue
> 
> If nobody has any objections, I'll merge this into master soon.
> 
> 2010/8/10 Asbjørn Ulsberg <asbjo...@gmail.com>
> 
> 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
> > >  i...@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
> > >  i...@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.
> 
> 
> -- 
> 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.
> 
> 
> -- 
> 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.

-- 
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.

Reply via email to