As far as I'm aware, if an entity is being saved, outside of being a
component/composite element, it is required to contain an Id of some
fashion. This is just the way NHibernate works, and it's another one of
those situations that if you think about it, makes sense, how else would it
be able to do
I suppose the drawback to this approach is that I have to introduce an
Id property that wasn't previously in my model. Something I guess I
will have to live with.
On Nov 4, 11:06 am, Will Smith wrote:
> My consumer class have a public proprerty of type IScheduleCriteria.
> There are multiple im
You've got the right idea, and yes, a separate table would be what's
required. However your schema is off slightly. JobSchedule would have a
JobScheduleCriteriaID (not the other way around). That's because the
reference to IScheduleCriteria is a many-to-one (Reference() in FNH) from
the side of Job
My consumer class have a public proprerty of type IScheduleCriteria.
There are multiple implementations if IScheduleCriteria some of which
derive from a base class for common behavior.
So if components don't support inheritance, then it sounds like I will
need two tables to map what I want. One
You're stating AutoMap, but you then state that you're only able to map the
properties on the interface. Are you using the Fluent Interface for mapping?
If not, give that a shot, AutoMap is great for simple greenfield solutions,
but really breaks down on more complex scenario's.
Also, you mention
I'd like to get this on the radar again. Can anyone out there help
me? Can FNH handle this scenario for me, or do I need to resort to
pure NH?
Please read the full thread for context.
Thanks,
Will
--~--~-~--~~~---~--~~
You received this message because you are
forgot to include my discriminator...
I would like to map something like this:
create table JobSchedule (
Id NUMBER(10,0) not null,
--many other fields
Criteria_Type VARCHAR2(255) not null,
Criteria_EffectiveStartDate TIMESTAMP(4) not null,
Criteria_StartTi
