I'm not sure how relevant this is to the solution to the sequenced
generators (obviously not an Oracle wizard), but I've been told they have
sprocs wrapping them so I can get a new ID this way.
------
Joe Brockhaus
joe.brockh...@gmail.com
------
On Fri, Nov 19, 2010 at 11:18 AM, Joe Brockhaus <fel0ni...@gmail.com> wrote:
> Well, I kinda just came up with that on the fly as I was trying to make
> sense of the replies :-S
>
> I haven't tried it yet, and honestly I'm not sure why it was causing my
> head scratching.
>
> Well, that's not entirely true. The mapping makes enough sense, but I
> suppose I'm still fuzzy on how my POCOs should look.
>
> my TicketBase properties need to be *public virtual*, not *public abstract
> *, right?
>
> I think my biggest hurdle is trying to reconcile the differences between
> well-designed POCOs and poorly-structured data. :-o
>
>
> With that in mind (and I don't want to stretch the scope of this thread *
> too* much):
>
> - The ticket tables each have a different, Oracle sequence generator
> for the PKs. How should I be mapping the ID field in light of this?
> - Some tables, like log notes, will be using composite keys: (ID +
> Date ~ unique). How do I map such a composite key with FNH?
> - Is there a way to have FNH/NH generate any DateTime fields
> automatically on save? i.e. - DateModified, DateCreated, etc. Perhaps even
> using a built-in Oracle function? We are currently setting these prior to
> persisting with NH in the service layer, but if there is a way to push
> those values closer to the actual commit time, I feel that would be best.
> (Not that we've identified any issue with that, yet, just trying to cover
> my
> bases..)
>
> Thanks for all your help!
> ~Joe
>
> ------
> Joe Brockhaus
> joe.brockh...@gmail.com
> ------
>
>
> On Fri, Nov 19, 2010 at 9:14 AM, Paul Batum <paul.ba...@gmail.com>wrote:
>
>> Asbjørn, I think your answer might be misleading to Joe. His suggestion is
>> certainly on the right track as I've done it myself in the past.
>>
>> Say you have these two class maps:
>>
>> TicketType1Map : ClassMap<TicketType1>
>> ...
>> ID(x => x.ID)
>> Map(x => x.Number)
>> Map(x => x.SomeCustomField1)
>>
>> TicketType2Map : ClassMap<TicketType2>
>> ...
>> ID(x => x.ID)
>> Map(x => x.Number)
>> Map(x => x.SomeCustomField2)
>>
>> You want to remove the duplication so you do this:
>>
>> public abstract class TicketBaseMap<T> : ClassMap<T> where T : TicketBase
>> {
>> public TicketBaseMap()
>> {
>> ID(x => x.ID);
>> Map(x => x.Number);
>> }
>> }
>>
>> public class TicketType1Map : TicketBaseMap<TicketType1>
>> {
>> public TicketType1Map()
>> {
>> Map(x => x.SomeCustomField1)
>> }
>> }
>>
>> public class TicketType2Map : TicketBaseMap<TicketType2>
>> {
>> public TicketType2Map()
>> {
>> Map(x => x.SomeCustomField2)
>> }
>> }
>>
>> Joe, the bit that has me confused is that you seem to already have this.
>> Are you encountering an error?
>>
>> 2010/11/16 Asbjørn Ulsberg <asbjo...@gmail.com>
>>
>>> If you have no TicketBase table, you need no TicketBaseMap. Just keep
>>> TicketBase abstract and FNH won't map it. Just map the classes that have
>>> tables and ignore the fact that they inherit TicketBase. NHibernate won't
>>> care.
>>>
>>>
>>> -Asbjørn
>>>
>>>
>>>
>>>
>>> On Mon, 15 Nov 2010 16:55:59 +0100, Joe Brockhaus <fel0ni...@gmail.com>
>>> wrote:
>>>
>>> You hit the nail on the head: each derived ticket class has its own
>>>> table:
>>>> there is no table for TicketBase.
>>>>
>>>> I was trying to reconcile how I would go about creating a TicketBaseMap
>>>> class and a DerivedTicketMap class and how the 2 would know about
>>>> eachother,
>>>> etc.
>>>>
>>>> Just to make sure I understand correctly, suppose the following:
>>>>
>>>> TicketTypeTable1
>>>> -- ID
>>>> -- Number
>>>> -- CreateDate
>>>> -- SomeCustomField1
>>>> -- etc
>>>>
>>>> TicketTypeTable2
>>>> -- ID
>>>> -- Number
>>>> -- CreateDate
>>>> -- SomeCustomField2
>>>> -- etc
>>>>
>>>> TicketBase
>>>> public abstract string ID
>>>> public abstract string Number
>>>> public abstract DateTime CreateDate
>>>>
>>>>
>>>> TicketType1 : TicketBase
>>>> public override string ID
>>>> public override string Number
>>>> public override DateTime CreateDate
>>>> public string SomeCustomField1
>>>>
>>>> TicketType2 : TicketBase
>>>> public override string ID
>>>> public override string Number
>>>> public override DateTime CreateDate
>>>> public string SomeCustomField2
>>>>
>>>> TicketType1Map : ClassMap<TicketType1>
>>>> ...
>>>> ID(x => x.ID)
>>>> Map(x => x.Number)
>>>> Map(x => x.SomeCustomField1)
>>>>
>>>> TicketType2Map : ClassMap<TicketType2>
>>>> ...
>>>> ID(x => x.ID)
>>>> Map(x => x.Number)
>>>> Map(x => x.SomeCustomField2)
>>>>
>>>>
>>>> I guess I was hoping to not have to do the mappings for the base types
>>>> in
>>>> each derived type's mapping class.
>>>>
>>>> Or should I also create a generic TicketBaseMap class that I could then
>>>> use
>>>> like so?
>>>> (It's not immediately clear to me what on ClassMap I would need to
>>>> override
>>>> to accomplish this)
>>>>
>>>> TicketType1Map : TicketBaseMap<TicketType1>
>>>> ...
>>>> Map(x => x.SomeCustomField1)
>>>>
>>>> I imagine i would start like so:
>>>>
>>>> TicketBaseMap<T> : ClassMap<T> where T : TicketBase
>>>>
>>>> ... but from there I'm not sure.
>>>>
>>>> Thanks!
>>>>
>>>> ------
>>>> Joe Brockhaus
>>>> joe.brockh...@gmail.com
>>>> ------
>>>>
>>>>
>>>> 2010/11/14 Asbjørn Ulsberg <asbjo...@gmail.com>
>>>>
>>>> On Wed, 10 Nov 2010 15:17:31 +0100, fel0nious <fel0ni...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> In code, I'll want to have something like TicketBase, with things like
>>>>>
>>>>>> TicketID, DateCreated, CreatedByUser, DateModified etc.
>>>>>>
>>>>>> and clearly I'd *like* TicketBase to be able to represent multiple
>>>>>> types of tickets. The problem is those different tickets are each
>>>>>> stored in a separate table, with *some* of the same properties [the
>>>>>> ones on the base class, ;-)] duplicated in each (but with the same
>>>>>> column names).
>>>>>>
>>>>>>
>>>>> Do you have a table representing TicketBase or do you only have tables
>>>>> for
>>>>> each "concrete" ticket instance? If there's no table storing what's
>>>>> common
>>>>> among all tickets, you can just have your TicketBase be abstract,
>>>>> derive
>>>>> from it and map all the derived classes explicitly to those tables.
>>>>>
>>>>> A bit more detail about how your tables look like would be helpful.
>>>>>
>>>>> --
>>>>> Asbjørn Ulsberg -=|=- asbj...@ulsberg.no
>>>>> «He's a loathsome offensive brute, yet I can't look away»
>>>>>
>>>>
>>> --
>>> 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.
