Does it mean I have to upgrade to NH 3? On 5 mai, 14:44, Fabio Maulo <[email protected]> wrote: > It will be with a test recreating the situation outside your > systemhttp://nhforge.org/blogs/nhibernate/archive/2008/10/04/the-best-way-t... > > On Thu, May 5, 2011 at 1:14 AM, Mark Kharitonov > <[email protected]>wrote: > > > > > Hi Fabio. > > > I guess I my description of the problem is not clear. There is no code > > to clear the table. But there is a code to delete the contents of > > unreachable collections, invoked from FlushCollections method > > (somewhere in the NH2 code base, I do not have the class name at this > > moment, but it is unambiguous). > > > Like I described, the AssociatedEndpoints is a noop property. > > Debugging the code I have noticed, that all the AssociatedEndpoints > > collections become unreachable from within the Commit statement and > > since they cover all the Endpoint_Protocol entries as a result of the > > Commit all of them are deleted. > > > Is it more clear this way? > > Thanks. > > > On May 5, 1:42 am, Fabio Maulo <[email protected]> wrote: > > > NH does not have code to clear a table, neither NH2 nor NH1. > > > Since NH2.1 *you* have an option to clear table/s representing a > > hierarchy > > > but nothing to clear a table representing a many-to-many table. > > > > That said... somebody else have cleared your tables but you can continue > > > hoping in a bug somewhere else ;) > > > > On Wed, May 4, 2011 at 4:36 PM, Mark Kharitonov > > > <[email protected]>wrote: > > > > > Anyone? > > > > > On 1 mai, 17:09, Mark Kharitonov <[email protected]> wrote: > > > > > Dear ladies and sirs. > > > > > I am not sure, if this is a bug, I am doing something wrong or this > > is > > > > > a bug in NH 2, but not NH 3 or later. > > > > > Anyway, we are using NH 2. > > > > > > I have two types of entities, here are the mappings: > > > > > > <class name="Protocol, Entities" lazy="true" table="Protocol"> > > > > > <id name="Id" column="Id" type="string" > > > > > > <generator class="assigned"/> > > > > > </id> > > > > > > <bag name="AssociatedEndpoints" table="Endpoint_Protocol" > > > > > access="noop"> > > > > > <key column="ProtocolId"/> > > > > > <many-to-many column="EndpointId" class="Endpoint" /> > > > > > </bag> > > > > > </class> > > > > > > <class name="Endpoint, Entities" lazy="false" table="Endpoint"> > > > > > <id name="Id" column="Id" type="int" > > > > > > <generator class="native"/> > > > > > </id> > > > > > > <bag name="SupportedProtocols" table="Endpoint_Protocol" > > > > > lazy="true"> > > > > > <key column="EndpointId"/> > > > > > <many-to-many column="ProtocolId" class="Protocol" /> > > > > > </bag> > > > > > </class> > > > > > > At some point, the database contains two endpoints and a dozen of > > > > > protocols - each endpoint is bound to each protocol. Meaning, the > > > > > Endpoint_Protocol table contains two rows per each protocol. > > > > > > Now, the server is restarted and one of the endpoints is refreshed. > > If > > > > > I throw away all irrelevant stuff (which has really nothing to do > > with > > > > > the problem), the relevant code is: > > > > > > using (var session = GetSession()) > > > > > { > > > > > var endpoint = FetchEndpoint(session, data.Id); > > > > > using (var transaction = BeginTransaction(session)) > > > > > { > > > > > transaction.Commit(); > > > > > } > > > > > } > > > > > > Unless I do not understand something really basic, this code should > > > > > have no effect whatsoever on the database. And yet, after Commit > > > > > returns there the Endpoint_Protocol table is empty! Only the > > relations > > > > > were deleted, the entities themselves are fine. > > > > > > After debugging it, I have noticed this: > > > > > * Commiting flushes the entities and the collections found in the > > > > > session, > > > > > * While flushing the entities, it marks all those collections, which > > > > > are values of the mapped properties of some flushed entity - these > > are > > > > > the reachable collections. > > > > > * When flushing the collections, the unreachable ones are deleted > > from > > > > > the database. > > > > > > What happens, is that the fetch endpoint is reachable - of course. It > > > > > maps the SupportedProtocols property, hence all the protocol entities > > > > > are reachable as well. However, an AssociatedEndpoints collection > > > > > linked to each protocol entity is not reachable, because no mapped > > > > > property of Endpoint references it (recall thenoopaccess). At least, > > > > > this is how the PocoEntityTuplizer extract the reachable values of > > an > > > > > entity - AssociatedEndpoints is not reachable according to it. > > > > > > Hence I witness these collections being deleted. > > > > > > Note, that once I remove the access="noop" making it the default > > > > > access and add the respective private property to the Protocol > > entity, > > > > > everything works just fine. > > > > > > What am I doing wrong? > > > > > > Thanks. > > > > > -- > > > > 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. > > > > -- > > > 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. > > -- > 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.
