James, I completely understand the reasoning behind removing
SetAttribute.
However, I've run into a mapping scenario that is (sort of) broken
(as it turns out there is another way around this) by the removal of
SetAttribute, namely when using CustomType with an ICompositeUserType.
I need to be able to do the following:
Map(x => x.AdminNumber)
.CustomType<CaseNumberType>()
.Columns.Add("MatterCaseType", "MatterOffice",
"MatterCaseNo");
where CaseNumberType is an ICompositeUserType.
The columns "MatterCaseType", etc.. are different from the default
columns names defined in CaseNumberType, which are "CaseType",
"Office", and "CaseNo". It doesn't seem to me to be a terribly unusual
situation.
However, the CustomType method will automatically add those default
column names defined in the ICompositeUserType to the Columns
collection, so the above mapping fails because we end up with 6 rather
than 3 columns.
I was able to get around this before by using
Map(x => x.AdminNumber)
.SetAttribute("type", typeof
(CaseNumberType).AssemblyQualifiedName)
.Columns.Add("MatterCaseType", "MatterOffice",
"MatterCaseNo");
I realize in many instances one might use a composite here instead,
but in this case I really need to call the constructor of the class
instantiated by the ICompositeUserType.
Looking at the code, I see that
Map(x => x.AdminNumber)
.CustomType(typeof(CaseNumberType).AssemblyQualifiedName)
.Columns.Add("MatterCaseType", "MatterOffice",
"MatterCaseNo");
Has the same effect as calling SetAttribute. It does not call
AddColumnsFromCompositeUserType() as the other overloads do. However I
only know this by reading the source. There's no particualr reason
that I, as the consumer of the API, should know that CustomType(type)
and CustomType( "typename" ) should have different behavior.
Would another set of overloads make sense here ?
CustomType<CaseNumberType>(CustomTypeOptions.CustomColumns)
CustomType<CaseNumberType>(CustomTypeOptions.DefaultColumns) (the
default)
Anyway, thanks for all the good work on this project!
Keith Klein
On Dec 2, 11:46 am, James Gregory <[email protected]> wrote:
> Composite Ids have been supported for a very long time, what about them
> can't you do? Use CompositeId() in your ClassMap.
>
> Tell us what the missing attributes are and we'll add them, but we've nailed
> 95% of them all.
>
> The concept of SetAttribute just doesn't work any more, because the entire
> implementation no longer relies on direct XML generation; we generate a
> semantic model from the interface and then transform that into whatever
> output format we please. To keep SetAttribute would require us to go out of
> our way to create hacks in the model to pass around extra attributes, and
> that time can be much better spent simply implementing the missing
> attributes.
>
> On Wed, Dec 2, 2009 at 6:03 PM, Andrew Ryan <[email protected]> wrote:
> > From the release notes:
>
> > •Removed SetAttribute - SetAttribute was a stop-gap measure to allow
> > people to use Fluent NHibernate when we didn't support the attributes
> > they needed. We've now gone to a great length to support all of the
> > main attributes in the fluent interface, so you shouldn't need this
> > anymore. If there are any attributes you need that we've missed, let
> > us know (or even better, send us a pull request/patch)
>
> > OK - there still seem to be several scenarios - such as the component
> > composite ID - where the proper attributes aren't supported. Given
> > that the SetAttribute was the only way to get around this limitation,
> > why would you guys make a breaking change like that? I mean, what was
> > the upside that balanced the downside of making it so that a bunch of
> > implementations broke with no workaround?
>
> > Just trying to understand,
> > Andrew
>
> > p.s. - How can I use a component/composite ID? Doesn't seem to be any
> > way now. And in my situation, I'm writing a SaaS application where the
> > ID has a partitionKey in it, so it's perfectly appropriate to be using
> > a composite/component key...
>
> > Thanks,
> > Andrew
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Fluent NHibernate" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<fluent-nhibernate%[email protected]>
> > .
> > 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en.
