How to... #52
Comments
|
I guess it's to do with the order. Perhaps @marco-brandizi can shed some light on this? |
|
This is what I get when unloading using the SimpleManager: 2012-05-11 11:06:27,264 []: an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) NOTE: Our entities do not have timestamp (don't ask me why!). Is this critical? |
|
Unloading is one part I haven't yet dug into. I understand the loading and persistence fairly well, but i'd need to check the mechanisms used for deciding what to unload. I would guess that the timestamp is required. I remember a conversation with marco a while ago about how things were unloaded and I believe that time was one thing used in the process. |
|
I haven't touched this code for quite a while (I'm no longer in this project), so I can only talk about what I remember. The submission timestamp of the objects to be possibly deleted is inspected to check whether it is the same as the timestamp of the study that was requested to delete. When I designed this we wanted to be able to delete reusable objects (e.g., ReferenceSource) if these are left unused and belonging to the same submission that is being deleted. This way of loading/unloading should be reviewed in favour of an approach that relies more on hibernate's cascading functionality. For the moment, best thing is to extend from unloaders of most similar object types (eg, MaterialUnloader should be the thing closest MetaboliteSampleUnloader). The most important thing that the loader/unloading code deals with is the operation's order and linking/unlinking things before/after a storage operation, so that Hibernate doesn't complain about referential integrity. |
1 similar comment
|
I haven't touched this code for quite a while (I'm no longer in this project), so I can only talk about what I remember. The submission timestamp of the objects to be possibly deleted is inspected to check whether it is the same as the timestamp of the study that was requested to delete. When I designed this we wanted to be able to delete reusable objects (e.g., ReferenceSource) if these are left unused and belonging to the same submission that is being deleted. This way of loading/unloading should be reviewed in favour of an approach that relies more on hibernate's cascading functionality. For the moment, best thing is to extend from unloaders of most similar object types (eg, MaterialUnloader should be the thing closest MetaboliteSampleUnloader). The most important thing that the loader/unloading code deals with is the operation's order and linking/unlinking things before/after a storage operation, so that Hibernate doesn't complain about referential integrity. |
|
Many thanks for your time...let see if I can solve it with your useful Cheers! On 11/05/2012 12:28, Marco Brandizi wrote:
Pablo Conesa Mingo |
Hi!
W have added in our fork 3 more entities to the model.
Study ---n--> AssayGroup --n-->Metabolite --n--> MetaboliteSample.
Load and save into the database works fine....but unloading is not working.
I have done this:
StudyUnloader.unload --> unloadManager.queueAll ( study.getAssayGroups() );
UnloadManager.unloaderClassses -->
// Pablo Conesa, add unloader for metabolites
new UnloaderMapping(AssayGroup.class, AssayGroupUnloader.class),
new UnloaderMapping(Metabolite.class, MetaboliteUnloader.class),
new UnloaderMapping(MetaboliteSample.class, MetaboliteSampleUnloader.class)
And I have created the correspondent unloaders:
AssayGroupUnloader, MetaboliteUnloader, MetaboliteSampleUnloader
Am I missing anything...this is not working!
Cheers!
The text was updated successfully, but these errors were encountered: