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