[hibernate-dev] 'key-many-to-one-element' and 'on-delete'
Hello Team, What do you think about adding "on-delete" attribute to "key-many-to-one-element" type in HBM mapping? This would allow generation of "ON DELETE CASCADE" clause. Context: "HHH-7807 - Deleting Revision Entity" and "HHH-8052 - Possibility to deleted audits/revisions in an orderly way". Regards, Lukasz Antoniak ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?
I'm planning on working on OGM-151. Fine with everyone? That will likely be my last before I move back to BVAL and close the final issues there. Emmanuel On Tue 2013-03-05 19:04, Sanne Grinovero wrote: > Nice! > n+1 is something Hibernate Search has to deal with too, that's why I > was interested in the fetch profiles and graph loading in JPA 2.1 > > On 5 March 2013 17:44, Emmanuel Bernard wrote: > > I have implemented a solution that gives an entity based on a tuple. > > https://hibernate.onjira.com/browse/OGM-273#comment-50082 > > > > Note that it does not currently works for MongoDB, but that's waiting > > for the dedicated GridDialect method as well as OGM-151. > > Also note that I have no idea how that will work for associations. I > > suspect some nasty n+1 is happening as best. Worse case, an exception :) > > > > Emmanuel > > > > On Tue 2013-03-05 10:30, Emmanuel Bernard wrote: > >> We might hope for a stable enough contract on Hibernate Search and > >> hope that we won't break serializability between micro or minor > >> versions. That will need to be taken into account in the test suite and > >> design. > >> On the OGM side though, we are not at that level of maturity and we will > >> force homogenous Hibernate OGM version across all the cluster. The grid > >> will have to go down for upgrades or enforce that no mpa reduce job > >> using OGM is used while the version roll out is in process. > >> > >> Emmanuel > >> > >> On Mon 2013-03-04 18:30, Sanne Grinovero wrote: > >> > Found an example, this is all the code it needs to have a MassIndexer > >> > working > >> > on top of Infinispan's Map/Reduce: > >> > > >> > https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/impl/massindex/IndexingMapper.java#L40 > >> > > >> > Note it's initialize method which injects needed components; the > >> > implementation is serialized across nodes. > >> > > >> > Sanne > >> > > >> > On 4 March 2013 18:26, Sanne Grinovero wrote: > >> > > We finished this discussion on IRC, in case someone else was > >> > > interested: > >> > > > >> > > hum I forgot the first step.. transformation from entry into > >> > > entity > >> > > updated > >> > > emmanuel, the "hidrate" step is what DavideD is bashing is > >> > > head against, but let's assume he finds a workaround and we focus on > >> > > the pattern as first step? > >> > > https://gist.github.com/emmanuelbernard/5084039 > >> > > sanne: ^ that's how I would do it if I had an Iterator from > >> > > the tuple > >> > > assuming pushToExecutor pushes to whatever concurrent work > >> > > mechanism you planned to use on consumes > >> > > Plus I am not folloing exactly how you plan consumes(Entry) > >> > > to be executed concurrently > >> > > is that the GridDialect responsibility? > >> > > That looks like a lot of work on the dialect's side > >> > > emmanuel, imagine the backend is Infinispan and has some large > >> > > amount of data per node, plus that each node has its own backend > >> > > IndexManager (like and ideal sharding) > >> > > ie pool mgt and cap + queuing > >> > > then with your approach the iterator needs to fetch data from > >> > > all remote nodes, and then enqueue in a local blocking queue which is > >> > > returning the data to the original owners > >> > > but if you skip that step, you can just forward the statless > >> > > consumer to each node and have it run on data locality > >> > > I was thinking that if you had the luncene index locally on > >> > > each node you would ahve a different impl of the MassIndexer anyways > >> > > that would simply send a command to each local node > >> > > To answer your question: that would be an optional GridDialect > >> > > responsibility. I would endorse a trivial first draft doing a > >> > > single-threaded loop. > >> > > and have GridDialect.getDataFor() returnlocal data > >> > > The "consumes" implementation can be either implemented with a > >> > > simple iterator - as in your design - so I don't think it pushes much > >> > > complexity to the GridDialect implementor? > >> > > The benefit of the consumer is that *optionally* it can be > >> > > mapped on the Map phase, and that's trivial if your backend supports > >> > > Map/Reduce > >> > > sanne: I don't follow that soory > >> > > how does that make it mappable to the Map phase? > >> > > "public void consume(Entry e) " is a degenerate (simplified) > >> > > form of map. > >> > > mm infinispan IDE crashes at the right moment. > >> > > I thought Map was about *filtering* > >> > > not processing > >> > > you can decide to accept 100% of values (without filtering), > >> > > but actually you might want to filter on the specified tables only. > >> > > also, the return type doesn't have to match the input type: > >> > > hence you define a transformation function, which is inherently > >> > > applied in parallel on all matching entries. > >> > > sanne: but then you require the OGM code to be everywhere >
Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?
it's ok for me Davide On Wed, Mar 6, 2013 at 3:28 PM, Emmanuel Bernard wrote: > I'm planning on working on OGM-151. Fine with everyone? > That will likely be my last before I move back to BVAL and close the > final issues there. > > Emmanuel > > On Tue 2013-03-05 19:04, Sanne Grinovero wrote: >> Nice! >> n+1 is something Hibernate Search has to deal with too, that's why I >> was interested in the fetch profiles and graph loading in JPA 2.1 >> >> On 5 March 2013 17:44, Emmanuel Bernard wrote: >> > I have implemented a solution that gives an entity based on a tuple. >> > https://hibernate.onjira.com/browse/OGM-273#comment-50082 >> > >> > Note that it does not currently works for MongoDB, but that's waiting >> > for the dedicated GridDialect method as well as OGM-151. >> > Also note that I have no idea how that will work for associations. I >> > suspect some nasty n+1 is happening as best. Worse case, an exception :) >> > >> > Emmanuel >> > >> > On Tue 2013-03-05 10:30, Emmanuel Bernard wrote: >> >> We might hope for a stable enough contract on Hibernate Search and >> >> hope that we won't break serializability between micro or minor >> >> versions. That will need to be taken into account in the test suite and >> >> design. >> >> On the OGM side though, we are not at that level of maturity and we will >> >> force homogenous Hibernate OGM version across all the cluster. The grid >> >> will have to go down for upgrades or enforce that no mpa reduce job >> >> using OGM is used while the version roll out is in process. >> >> >> >> Emmanuel >> >> >> >> On Mon 2013-03-04 18:30, Sanne Grinovero wrote: >> >> > Found an example, this is all the code it needs to have a MassIndexer >> >> > working >> >> > on top of Infinispan's Map/Reduce: >> >> > >> >> > https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/impl/massindex/IndexingMapper.java#L40 >> >> > >> >> > Note it's initialize method which injects needed components; the >> >> > implementation is serialized across nodes. >> >> > >> >> > Sanne >> >> > >> >> > On 4 March 2013 18:26, Sanne Grinovero wrote: >> >> > > We finished this discussion on IRC, in case someone else was >> >> > > interested: >> >> > > >> >> > > hum I forgot the first step.. transformation from entry into >> >> > > entity >> >> > > updated >> >> > > emmanuel, the "hidrate" step is what DavideD is bashing is >> >> > > head against, but let's assume he finds a workaround and we focus on >> >> > > the pattern as first step? >> >> > > https://gist.github.com/emmanuelbernard/5084039 >> >> > > sanne: ^ that's how I would do it if I had an Iterator >> >> > > from the tuple >> >> > > assuming pushToExecutor pushes to whatever concurrent work >> >> > > mechanism you planned to use on consumes >> >> > > Plus I am not folloing exactly how you plan consumes(Entry) >> >> > > to be executed concurrently >> >> > > is that the GridDialect responsibility? >> >> > > That looks like a lot of work on the dialect's side >> >> > > emmanuel, imagine the backend is Infinispan and has some large >> >> > > amount of data per node, plus that each node has its own backend >> >> > > IndexManager (like and ideal sharding) >> >> > > ie pool mgt and cap + queuing >> >> > > then with your approach the iterator needs to fetch data from >> >> > > all remote nodes, and then enqueue in a local blocking queue which is >> >> > > returning the data to the original owners >> >> > > but if you skip that step, you can just forward the statless >> >> > > consumer to each node and have it run on data locality >> >> > > I was thinking that if you had the luncene index locally on >> >> > > each node you would ahve a different impl of the MassIndexer anyways >> >> > > that would simply send a command to each local node >> >> > > To answer your question: that would be an optional GridDialect >> >> > > responsibility. I would endorse a trivial first draft doing a >> >> > > single-threaded loop. >> >> > > and have GridDialect.getDataFor() returnlocal data >> >> > > The "consumes" implementation can be either implemented with a >> >> > > simple iterator - as in your design - so I don't think it pushes much >> >> > > complexity to the GridDialect implementor? >> >> > > The benefit of the consumer is that *optionally* it can be >> >> > > mapped on the Map phase, and that's trivial if your backend supports >> >> > > Map/Reduce >> >> > > sanne: I don't follow that soory >> >> > > how does that make it mappable to the Map phase? >> >> > > "public void consume(Entry e) " is a degenerate (simplified) >> >> > > form of map. >> >> > > mm infinispan IDE crashes at the right moment. >> >> > > I thought Map was about *filtering* >> >> > > not processing >> >> > > you can decide to accept 100% of values (without filtering), >> >> > > but actually you might want to filter on the specified tables only. >> >> > > also, the return type doesn't have to match the input type: >> >> > > hence
Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?
I've successfully implemented OGM-151 for EntityKey which is the one we need to move OGM-273 forward for now. I am trying to implement it for AssociationKey but caching here is significantly harder as data is cross reference across associations. Sanne, when you worked on the profiling of OGM, do you remember AssociationKey putting a pressure in build time or memory wise? Because caching them per persister means some rather complex race conditions and more memory used permanently (as opposed to on demand). So I'm wondering if that's worth it. As an intermediary step, I could introduce AssociationKeyMetadata but build it on-demand - that one is easier to achieve. Emmanuel On Wed 2013-03-06 15:32, Davide D'Alto wrote: > it's ok for me > > Davide > > On Wed, Mar 6, 2013 at 3:28 PM, Emmanuel Bernard > wrote: > > I'm planning on working on OGM-151. Fine with everyone? > > That will likely be my last before I move back to BVAL and close the > > final issues there. > > > > Emmanuel > > > > On Tue 2013-03-05 19:04, Sanne Grinovero wrote: > >> Nice! > >> n+1 is something Hibernate Search has to deal with too, that's why I > >> was interested in the fetch profiles and graph loading in JPA 2.1 > >> > >> On 5 March 2013 17:44, Emmanuel Bernard wrote: > >> > I have implemented a solution that gives an entity based on a tuple. > >> > https://hibernate.onjira.com/browse/OGM-273#comment-50082 > >> > > >> > Note that it does not currently works for MongoDB, but that's waiting > >> > for the dedicated GridDialect method as well as OGM-151. > >> > Also note that I have no idea how that will work for associations. I > >> > suspect some nasty n+1 is happening as best. Worse case, an exception :) > >> > > >> > Emmanuel > >> > > >> > On Tue 2013-03-05 10:30, Emmanuel Bernard wrote: > >> >> We might hope for a stable enough contract on Hibernate Search and > >> >> hope that we won't break serializability between micro or minor > >> >> versions. That will need to be taken into account in the test suite and > >> >> design. > >> >> On the OGM side though, we are not at that level of maturity and we will > >> >> force homogenous Hibernate OGM version across all the cluster. The grid > >> >> will have to go down for upgrades or enforce that no mpa reduce job > >> >> using OGM is used while the version roll out is in process. > >> >> > >> >> Emmanuel > >> >> > >> >> On Mon 2013-03-04 18:30, Sanne Grinovero wrote: > >> >> > Found an example, this is all the code it needs to have a MassIndexer > >> >> > working > >> >> > on top of Infinispan's Map/Reduce: > >> >> > > >> >> > https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/impl/massindex/IndexingMapper.java#L40 > >> >> > > >> >> > Note it's initialize method which injects needed components; the > >> >> > implementation is serialized across nodes. > >> >> > > >> >> > Sanne > >> >> > > >> >> > On 4 March 2013 18:26, Sanne Grinovero wrote: > >> >> > > We finished this discussion on IRC, in case someone else was > >> >> > > interested: > >> >> > > > >> >> > > hum I forgot the first step.. transformation from entry > >> >> > > into entity > >> >> > > updated > >> >> > > emmanuel, the "hidrate" step is what DavideD is bashing is > >> >> > > head against, but let's assume he finds a workaround and we focus on > >> >> > > the pattern as first step? > >> >> > > https://gist.github.com/emmanuelbernard/5084039 > >> >> > > sanne: ^ that's how I would do it if I had an Iterator > >> >> > > from the tuple > >> >> > > assuming pushToExecutor pushes to whatever concurrent > >> >> > > work > >> >> > > mechanism you planned to use on consumes > >> >> > > Plus I am not folloing exactly how you plan > >> >> > > consumes(Entry) > >> >> > > to be executed concurrently > >> >> > > is that the GridDialect responsibility? > >> >> > > That looks like a lot of work on the dialect's side > >> >> > > emmanuel, imagine the backend is Infinispan and has some > >> >> > > large > >> >> > > amount of data per node, plus that each node has its own backend > >> >> > > IndexManager (like and ideal sharding) > >> >> > > ie pool mgt and cap + queuing > >> >> > > then with your approach the iterator needs to fetch data > >> >> > > from > >> >> > > all remote nodes, and then enqueue in a local blocking queue which > >> >> > > is > >> >> > > returning the data to the original owners > >> >> > > but if you skip that step, you can just forward the statless > >> >> > > consumer to each node and have it run on data locality > >> >> > > I was thinking that if you had the luncene index locally > >> >> > > on > >> >> > > each node you would ahve a different impl of the MassIndexer anyways > >> >> > > that would simply send a command to each local node > >> >> > > To answer your question: that would be an optional > >> >> > > GridDialect > >> >> > > responsibility. I would endorse a trivial first draft doing a > >> >> > > single-threaded loop. > >> >> > >
