Hi Tony
What about using inheritance but leave out the ACCOUNT field in the parent
and put it in the respective child classes. So then the one child class will
have registrationNumber and the other will have accountNumber, but both of
these will point to the same ACCOUNT field in the DB.
Jurgen
-----Original Message-----
From: Tony Giaccone
Sent: Thursday, October 24, 2019 11:43 PM
To: user@cayenne.apache.org
Subject: Using inheritance.
General question..
I have a situation where I am building a service to handle processing
requests. These requests come from several client systems to handle to
"different" objects, which are actually very close to identical. In
particular, they do have one field which is identical in function but has
different names in the source systems that we are fronting. For the
purposes of this discussion let's say they are called Account Number in one
system and Registration Number in a second system.
I have an account_table which is an example of horizontal inheritance. All
the fields of both objects exist in his table. Originally the plan was to
have two unrelated entities which shared the same table, but were not
related by inheritance in java. This made things easy because I could just
call the fields different names in different entities and they both
referred to the same field in the table.
Some use cases have come up that mean it would be valuable to have them
related by inheritance in java as well. My problem now is how to deal
with this attribute that is stored in the same column but has different
names in the two entities.
As I see it, I have a couple of choices and I'm looking for opinions on how
to proceed.
1) I could just leave them as separate entities that share a table. This
keeps the encapsulation strong and makes life simpler in some ways, but
means anytime I search against one, I have to search against two. Not
ideal, but manageable. if I go down this path, I will probably write two
end points one for each entity.
2) Implement Inheritance and create a cover method, with the correct domain
specific name, that references the inherited "common" field. This feels
like a nightmare for writing queries and inserts. It has the advantage of
maintaining domain level naming.
3) Bite the bullet and change the name to be consistent in the two objects
and refactor a bunch of code. This feels clean to implement but also feels
confusing for developers because semantically different fields share a
name, in this system and no other.
4) Make the "parent" class specific to the use case that's causing the
problem. Don't use inheritance. Just three entities that are all based on
the same table. Write one piece of custom SQL that updates this object
when it needs to be modified independent of the qualifier.
uggh, Which of the four that I outlined would you suggest, or is there
another idea that works better?
Tony
