Hi there,

I am having a design question I would like to get some feedback on. Since the core of the application using Hibernate together with Hibernate Annotations I thought I post the question here first. Maybe there is neat little Hibernate feature I could use?

Here is the problem. I have a Company entity with the usual properties like name, organization number, etc. There are also quite a few associations like for example to addresses, contacts, financial information, etc. I think the exact structure is not so important. The data comes from a back end system which exports into a XML file which we in turn parse in order to populate our db with entities.

So far quite simple, right? Now it gets a little more complicated. The application is also supposed to handle incremental updates (new companies and or changes to existing ones). The backend system send xml files again. The problem is not so much to insert or update the existing companies, but rather that a user can decide to montior/watch a company for changes. If a change occurs he should be notified that eg the address of company X has changed. I don't have to keep the full history of changes. It would be sufficient to keep the 'change' information until everyone who monitors this particular company has seen the change.

By the way - we are talking about 240 000 companies, not counting all the associated entities. It feels like a quite common use case. Maybe someone has solved a similar problem before and wants to share his knowledge.

Any thoughts or brain storming ideas welcome :)

--Hardy

I would think of a db/hibernate solution. In the db you can put a trigger on the tables and you can have the watchers in another table. If an entity being updated is watched by some one then you put a data somewhere else, and I guess you can tell the rest...


Farzad-

You have tons of options (Not sure if this is a good thing)

- the DB way: have an update trigger that looks up interestet users and informs them (via e-mail or some entry in a message table or whatever)
Pro: works also when changes come in some other way

- the hardcore hibernate way: you could register Eventhandler on your hibernate session to detecht changes.
Pro: this aproach is not dependent on the objects useres want to watch, so you don't have to change the company class for this to work, and it is all in java so a reference search on User will bring up the eventhandler

- the pure simple Java way: have a persistent Set of Listeners (i.e. Users), that get informed when any of the properties of the Company changes.
Pro: Very simple to understand, no magic DB or Hibernate Trigger, which some people might have problems to find and understand

Thanks for the replies. I guess there is just no silver bullet. Here is another idea I had. One could create a CompanyMonitior object. I don't want to store a full copy of the company object in the db when a company gets updated. Also, not all changes to the object should trigger a notification and I need a way to add meta information to the change. For example if the address changes I want to say "Foobar's address has changed".

With the CompanyMonitor object I want to achieve the following. using for example standard bean notation I configure which properties I am interested in. On top of things i can group properties into groups so that I I detect a change within a group I can display some meta information.

The idea is now that when a user creates a monitor on Company X, I pass this company to the CompanyMonitor class and via introspection extract all the values I am interested in. I can put them into hashmaps for example. Then I persist the CompanyMonitor together with the original object id. Via a scheduled job I can then regularly retrieve the Company entity again, create the CompanyMontior again and compare it with the persisted version.

I am hoping that with this approach it would be easier to detect changes. I just have to compare simple key value pairs. I also have more control which properties trigger a notification and which 'type' of change occurred.

I am not sure if this makes sense to anyone except me right now :)

You can definitely have a solution like this. Specially if you use something like AspectJ your life will be a lot easier. The key here however is to also hook into the transaction manager's call backs so you know which changes made it to database. This a little too much complexity that you might want to avoid. Still I prefer a database trigger solution. It's, in theory, the most efficient way.


Farzad-