Podría utilizar una estrategia de table per subclass, en la cual la clase principal sea abstracta?? ya se esto seria una table-per- concrete-class, pero cambiaría los mappings y la forma de realizar las consultas a bb.dd. y seria mas correcto desde un punto de vista relacional.
Un saludo On 28 ene, 13:52, Victor Mingueza <[email protected]> wrote: > La verdad es que tengo muy en cuenta tus palabras, pero el modelo me > va a venir definido al menos algunas de estas tablas Concrete, por lo > que quería realizar el menor impacto sobre estas ya que puede ser que > la respuesta a la modificación sea no y me tira todo el trabajo abajo. > Así que pensándolo mucho es la única forma que tengo para hacerlo para > poder establecer una jerarquía entre mis clases aunque sea > implementando una interfaz. > > Revisando las opciones de nuevo...he encontrado que la colección <many- > to-one admite un campo property-ref en el caso de que esta no se > relacione con la clave primaria de mi tabla principal, pero me genera > una excepción ya que no puedo usar este campo porque no me lo admite > el esquema Xml, aunque en la documentación pone que si es valido. > Estoy usando este esquema xmlns="urn:nhibernate-mapping-2.2" > > Paso a detallar esto un poco antes de que se me coman :-) porque según > he visto en la documentación no es una buena practica y se desaconseja > totalmente. > El caso es que mis tablas Concrete, ademas de tener si Id de tipo > entero autonumérico, van a tener otro campo de tipo Guid que sera mi > clave primaria para NHibernate, pero para las relaciones con otras > tablas que me vienen ya definidas quiero que se siga manteniendo la > relación a través de su ID principal. Solo utilizare una relación a > las claves Unique para aquellas tablas que sea necesario hacer una > relación con el objeto abstracto Anexo el cual el campo Guid me > permitirá saber de que tabla se trata al ser único en la BB.DD. > > De todas formas voy a investigar un poco mas con la opción que me has > dado de las <subclass><join> a ver si podría aplicarla. > > Un saludo y gracias por todo :-D > > On 28 ene, 13:08, Fabio Maulo <[email protected]> wrote: > > > > > Y otra cosa... ante de usar table-per-concrete-class hay que pensarlo unas > > 25 veces. Si solo llegaste a pensarlo 4 te faltan otras 21. > > > El 28 de enero de 2010 05:37, Victor Mingueza > > <[email protected]>escribió: > > > > Mi idea seria algo así, > > > > <?xml version="1.0" encoding="utf-8" ?> > > > <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" default- > > > lazy="false"> > > > <class name="IAnexable, Namespace" > > > dynamic-update="true" > > > dynamic-insert="true" > > > lazy="true" > > > abstract="true"> > > > > <union-subclass name="ConcreteAnexo2" table="ConcreteAnexo2" > > > lazy="true" > > > dynamic-update="true" > > > dynamic-insert="true" > > > extends="IAnexable" > > > abstract="false"> > > > > <id name="Id" column="Id" type="System.Int32" unsaved- > > > value="0"><generator class="native"/></id> > > > <property .... /> > > > ..... > > > </union-subclass> > > > > <union-subclass name="ConcreteAnexo2" table="ConcreteAnexo2" > > > lazy="true" > > > dynamic-update="true" > > > dynamic-insert="true" > > > extends="IAnexable" > > > abstract="false"> > > > > <id name="Id" column="Id" type="System.Int32" > > > unsaved- > > > value="0"><generator class="native"/></id> > > > <property .... /> > > > ..... > > > </union-subclass> > > > > </class> > > > </hibernate-mapping> > > > > ¿Es posible esto? Un saludo y gracias por vuestro tiempo. > > > > On 28 ene, 09:26, Victor Mingueza <[email protected]> wrote: > > > > Si no me equivoco, usando subclass no puedo indicar la tabla a la cual > > > > quiero que mapee mi objeto, con lo que estaría usando la estrategia de > > > > Table per class Hierarchy, y me mapearia todas las clases concretas > > > > sobre la misma tabla y no es el objetivo. > > > > > El objetivo es usar una tabla por cada clase concreta, las cuales > > > > heredan todas de una misma interfaz, pero sino me equivoco aquí no > > > > puedo usar identity para que el SGBD, se encargue de generar mi clave > > > > primaria. En la cual no quiero que hayan saltos sino que sean números > > > > correlativos para cada una de mis tablas. ¿Es esto posible? y si > > > > podéis darme alguna guía ya que en la documentación no veo ejemplos > > > > sobre esto. > > > > > Pensándolo bien el discriminador no seria necesario. Ya que yo podría > > > > hacer una query para obtener un objeto concreto con una consulta del > > > > tipo s.Get(typeof(ConcreteAnexo1)(1), cuando sepa que es de este tipo, > > > > en lugar de algo como esto s.Get(typeof(IAnexable)(1,"ConcreteAnexo1") > > > > > Un saludo > > > > > On 27 ene, 19:30, Fabio Maulo <[email protected]> wrote: > > > > > >http://nhforge.org/doc/nh/en/index.html#mapping-declaration-subclass > > > > > que el campo discriminator sea parte de la PK no lo vas a encontrar ya > > > que > > > > > no es la def. en ORM. > > > > > En ORM el POID es univoco adentro una gerarquia de clases o univoco en > > > todo > > > > > el dominio así que no hace falta usar una clave compuesta para eso. > > > > > > El 27 de enero de 2010 14:03, Victor Mingueza > > > > > <[email protected]>escribió: > > > > > > > Hola Buenas a todos, > > > > > > > Quería saber si exista la posibilidad de usar esta opción en > > > > > > NHibernate, ya que en la documentación no he visto ningún ejemplo de > > > > > > como hacerlo y no me parece en principio una forma tan rara de > > > > > > realizar la herencia. > > > > > > > Os paso a explicar el caso para que quede un poco mas claro. Mi > > > > > > sistema permite que unos objetos en concretos sean Anexables a > > > > > > otros, > > > > > > es decir > > > > > > > Mi elemento A tiene una colección de objetos Anexos los cuales > > > > > > pueden > > > > > > ser del tipo ConcreteAnexo1, ConcreteAnexo2...los cuales implementan > > > > > > todos las interfaz Anexos que define una serie de propiedades > > > > > > comunes > > > > > > > Pero mis ConcreteAnexo no quiero que compartan el mismo > > > identificador, > > > > > > es decir en la tabla ConcreteAnexo1 no quiero que hayan saltos en el > > > > > > Id, porque este se ha usado en un registro de ConcreteAnexo2. > > > > > > > Sino que la clave de mi table ConcreteAnexo1 fuera solo el > > > > > > identificador mas el campo discriminador que no sera parte de la > > > clave > > > > > > primaria. Aunque NHibernate si use este discriminador primero para > > > > > > diferenciar entre las distintas tablas cuando se haga una consulta > > > por > > > > > > un Id concreto evitando hacer la select de cada una de las tablas > > > > > > ConcreteAnexo. y por ultimo usar ambos campos la PK y Discriminador > > > > > > para diferenciar varios objetos de tipos concreto distintos. > > > > > > > Un saludo y gracias por vuestro tiempo. > > > > > > > -- > > > > > > Para escribir al Grupo, hágalo a esta dirección: > > > > > > [email protected] > > > > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano > > > > > > -- > > > > > Fabio Maulo > > > > -- > > > Para escribir al Grupo, hágalo a esta dirección: > > > [email protected] > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano > > > -- > > Fabio Maulo -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
