Referential Integrity in Data Objects
I'm sure this has been discussed before, but i have not been able to find a solution for this problem.
I am working on a system that stores data objects in a relational database. The data objects A are arranged in a parent/children relationship, data objects B reference instances of A. Since i have no access to all equal instances of any of the objects, i cannot guarantee that a change of one instance will actually reach all other objects. To make matters worse, i can only guarantee that the database delivers equal objects for a given ID, but not the same instance for each call.
Originally, i wanted the classes to reference their children's/parents' IDs instead of the objects themselves. This would have solved the problem, however, i need some properties of the actual objects and neither A nor B can have access to the database.
Anyone know a solution or a design pattern on similar matters?
Not sure if this will help, but here goes. In a good relational database design, you should rarely have to propogate changes. Good design involves normalizing data such that the data is repeated or stored as few times as possible. If you are having to cascade changes to like instances across multiple copies, consider creating a new "parent" table that will be changed instead. True, you will have to join to one more table in many instances, but you have a cleaner relational design that is closer to the spirit of the technology.
Without more specifics, I cannot be sure what the actual problem is.
- Saish
"My karma ran over your dogma." - Anon
You might find some useful information from this project: http://www.hibernate.org/it provides some discussion of persisting parent child relationships: http://www.hibernate.org/hib_docs/reference/html_single/#parent-childthanksalex
> You might find some useful information from this project:> http://www.hibernate.org/> I agree - Hibernate is the way to go. - MOD
> I am working on a system that stores data objects in a
> relational database. The data objects A are arranged
> in a parent/children relationship, data objects B
> reference instances of A. Since i have no access to
> all equal instances of any of the objects, i cannot
> guarantee that a change of one instance will actually
> reach all other objects.
I assume that you mean that instances that are associated with the DB records are being used in different JVMs. Is that the case?
> To make matters worse, i can
> only guarantee that the database delivers equal
> objects for a given ID, but not the same instance for
> each call.
Why not? Not that I am doubting you, I just need to understand why that is is the case? Mulitple app servers? Actually, first, are you using J2EE?
> Originally, i wanted the classes to reference their
> children's/parents' IDs instead of the objects
> themselves. This would have solved the problem,
> however, i need some properties of the actual objects
> and neither A nor B can have access to the database.
I don't understand this. Why aren't the primary keys stored in the Objects?
> Anyone know a solution or a design pattern on similar
> matters?
If I understad the problem correctly this is usually solved by using optimistic locking. If you actually want to propogate changes around it's a little more complicated but I've done it.
> it provides some discussion of persisting parent child
> relationships:
> http://www.hibernate.org/hib_docs/reference/html_single
> #parent-child
If I understand the OP correctly, I don't think this applies. I think the issue is that there are many instances of a class that all represent the same record. The issue is keeping all instances in sycn with each other. But I could be misunderstanding the issue.
> there are many instances of a class that all represent the same recordthat is exactly it. currently, i try to change cloned references to a central one for each object that passes through the data manager, but that seems somewhat awkward
> that is exactly it. currently, i try to change cloned
> references to a central one for each object that
> passes through the data manager, but that seems
> somewhat awkward
Can you expand on that? I don't follow you. Also, Can you answer the other questions I have asked.
Hi Night-Stalker,
"working on a system that stores data objects in a relational database"
Depending on the complexity of the objects, its hierarchy and the db-system operations, you may choose one these.
1) Too Complex system- Use Object oriented database.
2) Mediocre complex system- Use Object - relational mapping tools . Example
http://otn.oracle.com/products/ias/toplink/technical/tl10g_faq.htm
3) Not Complex/ Minimal requirements - Use JDBC and write a system for yourself (If you are intrested, use the open sources, you may find on net.) I have searched and found these good for you.
http://www.onjava.com/pub/a/onjava/2003/01/08/ojb.html
http://www.javalobby.com/thread.jspa?forumID=17&threadID=8996
This system can be tailor made to suit your requirements.
"The data objects A are arranged in a parent/children relationship, data objects B reference instances of A. Since i have no access to all equal instances of any of the objects, i cannot guarantee that a change of one instance will actually reach all other objects. To make matters worse, i can only guarantee that the database delivers equal objects for a given ID, but not the same instance for each call.
Originally, i wanted the classes to reference their children's/parents' IDs instead of the objects themselves. This would have solved the problem, however, i need some properties of the actual objects and neither A nor B can have access to the database."
One of the above choices would solve these problems. But hold on, they are not as ready-to-use as is told about it. You may have to use/configure/develop it with great care. One example is of your query regarding ID. You have to take care by compulosorily using a primary key for all, establish how to apply equals() and et al.
Hibernate, as suggested in this forum is also a good bet.
Originally, i wanted the classes to reference their children's/parents' IDs instead of the objects themselves.
All the choices listed above include this solution.
Anyone know a solution or a design pattern on similar matters?
1) My suggetsions and that of others can be good solutions.
2) Usage of design pattern can be focussed only if you are going to develop your own object-relational mapping system. (as in choice 3).
Hope this helps.
Wish you all the best.
Rajesh
> > there are many instances of a class that all
> represent the same record
>
> that is exactly it. currently, i try to change cloned
> references to a central one for each object that
> passes through the data manager, but that seems
> somewhat awkward
The first question I usually ask when I see this sort of question is...does it really matter?
It is quite easy to come up with test cases that cause data problems in a database and yet those test cases do no represent anything that can actually happen in the business system.
For example two people change the billing address of a customer to two different addresses. This sort of thing just can't happen except in vary extreme circumstances (like a divorced couple fighting over the legal address of the child and they both call up at the exact same time to change the address.)
And if really necessary then there is a simplistic solution. For each record keep a last update time. For each 'different' record it also keeps the update time. When you go to write the record, compare the times, if they are different then throw an exception.
After that you are going to get into much more complex solutions.
Hava a look of Java Data Objects in http://java.sun.com/products/jdo/javadocs/index.html , http://www.jdocentral.com/ , http://java.sun.com/products/jdo/index.jsp . Rajesh
