Ok for legacy DB and sorry because I don't saw the patch.I will study the
patch to apply it in trunk.
BTW identity still a bad choice to work with ORM for various reasons and
probably you know why.
Bye.
Fabio.

P.S. Probably I will change something to support all
PostInsertIdentifierGenerator

2008/9/30 James Nail <[EMAIL PROTECTED]>

>
> I know that NHibernate plays nicer with Guid primary keys, Hi/Lo, or
> other strategies.  Unfortunately in practical terms, we don't always
> have the freedom to make such choices (whether it's a legacy DB or
> just decisions made by higher-ups with different design priorities).
>
> I noticed that someone included a patch on the jira bug (
> http://jira.nhibernate.org/browse/NH-727, patch:
>
> http://jira.nhibernate.org/secure/attachment/12230/nh_727-identity-sql-insert.patch
> ) which proposed a fix for this.  Has anyone looked at this proposed
> fix to see if it works, or if it's appropriate?
>
> The ability to use custom SQL insert & update statements are very
> important when trying to map to non-standard table structures (again,
> Legacy or simply different design priorities).  In our case, in the
> standard inheritance mapping strategies (table-per-subclass, table-per-
> hierarchy, table-per-concrete class) aren't acceptable to our DBA, for
> various reasons.  We figured that since NHibernate promises so much
> extensibility, we could fairly easily try a hybrid approach to such a
> mapping, using stored procs for inserts and updates.  Unfortunately,
> those efforts hit a brick wall when we realized that NHibernate
> doesn't know how to handle custom SQL inserts when the primary key is
> generated by the DB.
>
> It seems that even if the id SQL parameter created by NHibernate to
> pass into the custom SQL insert used the unsaved-value from the
> mapping (or just didn't get passed in at all for entities that use
> identity PKs), we could at least work around that by assigning a
> default value to the param in the stored proc.  The fact that it
> passes in @p4=default prevents our SQL from handling this at all.
>
> Does this sound workable, or am I missing something more fundamental
> here?
> >
>


-- 
Fabio Maulo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"nhusers" 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/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to