Entity classes from database questions

[Jeffrey H. Coffield]

I have been thru several of the NB tutorials and have some code working
but there are a few things that don't make sense to me (yet).

I have a MySQL table MenuCounts with three fields as the primary key.
They are a phone number, a menu name and a menu item. There is another
field that counts how many times that menu item was accessed. When I
create the entity class, there is no named query for the entire primary
key, just a "findAll" and a find for each of the individual fields. So I
have to add a new named query to get the particular count I want to
update. Now if I need to add a new field and want to regenerate the
class, it erases my addition. This seems odd.

Also there is a second class created as MenuCountsPK and I can sort of
see that this allows so generic testing of equality for the entire key
but now all the fields in the key can only be accessed as
x.getMenuCountsPK().getPhoneNumber, etc. This means the business logic
now has to know that these fields are special and need different code to
access that other fields. This seems also seems odd.

I would like to wrap these two classes with another class
(WrapMenuCounts) that contains a getPhoneNumber, etc. that works right
and would also have the missing named queries but that gives me problems
with various errors like ClassCastException as the result set from a
query is a MenuCounts object and not a WrapMenuCounts object.

It has been my experience that one of the most common changes to an
application is to add new fields into the tables to support new features
and add new keys to speed things up so wrapping the generated code seems
like it would be a good approach. Does anyone have an example of this?

TIA,

Jeff Coffield

[jhalupka]

I've found dealing with compound primary keys difficult too. My web app began
with a 35 table database that has grown to a 55+ table database. Most of my
entities have some custom code to support data binding.

What I do is auto-generate entities from the new tables and manually "fix"
existing entities (add fields, relationships, queries, etc.).

Adding new columns to an entity has also caused me a few headaches,
especially if I've modified the entity. IMO, auto-generating an entity after
it already exists isn't a good idea. What I do is manually code the new
columns and any foreign key relationships. It may appear to be more time
consuming, but all previous code changes are preserved.

One thing you could do is to add a getPhoneNumber/setPhoneNumber methods to
the MenuCounts entity. This will (somewhat) hide the fact that the field you
want is "buried" in the primary key class.


Jeffrey H. Coffield wrote:

[Javier.Ortiz]

That's a nice question. There should be a way but I haven't figured it out yet. Also created a question in stackoverflow just in case someone else answers it outside of this list.

http://stackoverflow.com/questions/3711770/is-there-a-way-to-define-namedqueries-outside-of-entity

Javier A. Ortiz Bultr

[Javier.Ortiz]

What about defining the custom queries in the persistence file like:

<named-query name="xxxxxx">
<query>
<![CDATA[
SELECT x FROM XXXXXXXX x
]]>
</query>
</named-query>

Javier A. Ortiz Bultr

[Grover Blue]

Regarding the wrapping class, can you just modify the existing Entity classes to have a field like such:

@Column(name = "PHONENUMBER", insertable = false, updatable = false)
private String phoneNumber;

Make sure that the EmbeddedId class has it's field name for phone number set to "PHONENUMBER" as well.

[Jeffrey H. Coffield]

address-removed wrote:

[Jeffrey H. Coffield]

Futaleufu_John wrote:

[Jeffrey H. Coffield]

Grover Blue wrote:

[Javier.Ortiz]

Forgot to add that that goes within the <persistence-unit> tags so you need to define them in a per persistence unit basis.

Javier A. Ortiz Bultr

[Javier.Ortiz]

Usually this doesn't happen often. In my case it doesn't, spent a lot into DB design that pays out afterwards. Anyway, I leave all the Entity generation to Netbeans, its pretty good at it. I usually have my code under version control so any minor tweaks I do to the entities I can recover from version control from within the IDE itself but this should be the exception.

You want to avoid customizing the Entities as much as possible since if you are planning using the JPA Controllers down the road it'll make keeping the customizations a nightmare. Of course you can do all this by hand but then you lose all the automation and waste time you could invest in managing the real important code.

At least for me it works like this:

• Spend a good amount of time designing application/database, UML will help a lot
• Make sure the tables are normalized to reduce the amount of changes later[1]
• Write Unit Testing for database access and interactions
• After the database layer is done start working with the rest.

I have spent weeks or even months in first two steps but later down the road I don't need to change the databases unless I'm adding features/requirements.

Just my 2 cents...

[1] http://en.wikipedia.org/wiki/Database_normalization

Javier A. Ortiz Bultr