This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am using sample code from a spring persistence book that uses 2 interfaces: DomainObject and GenericDao
The problem is that the interfaces assume that the id of the domain object is always a long integer. In my case I have a domain object that has a composite key (OrderLinePK). I thought that I could fix this by implementing generics in DomainObject
The problem is how am I going to amend GenericDao to use DomainObject's generic parameter.
I know I could easily scrap the DomainObject and GenericDao interfaces, but would like to see how i can adapt the code for my requirements.
Stephan van Hulst wrote:Well, I think a generic type is hardly appropriate for an ID. Why do you want to return such a composite key as an ID?
Totally agree. And furthermore, in database terms, a composite key cannot be an ID. What it can be is a primary key, which is something completely different.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Joined: Aug 18, 2010
Ok, here's some background info. GenericDao is later implemented as a generic hibernate data access object that uses hibernateTemplate. the get method in hibernateTemplate accepts a serializable parameter as an ID.
The composite key OrderLinePK is a serializable class used to represent the composite key in OrderLine. I would like to amend GenericDao to support keys other than Long ids.
Joined: Aug 18, 2010
My question is not related to the hibernate/database aspect, I only mentioned that to explain what I would like to achieve.
Without having tested it, I'd try something like this:
What I think I'd really do, if I had enough control over the database, would be to get rid of the composite key, add a surrogate Long primary key (autoincrementing field, for example), and add the composite as an additional unique key.