Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Cecil Westerhof <Cecil@decebal.nl>
Newsgroups: comp.lang.java.programmer
Subject: Re: JPA and extra fields
Date: Mon, 17 Aug 2015 07:40:25 +0200
Organization: Decebal Computing
Lines: 56
Message-ID: <87vbcescae.fsf@Equus.decebal.nl>
References: <87zj1v3vnq.fsf@Equus.decebal.nl> <mqir44$15b$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="25738"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188W63jXQBNCkHHpufP611R8YB/WejXFjM="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
X-Homepage: http://www.decebal.nl/
Cancel-Lock: sha1:gHvNfLbNY9Cema5jUZmDVHMH9PQ= sha1:QPq7T2QeUJxHI6uD59zd6smbTS8=
Xref: csiph.com comp.lang.java.programmer:32332

On Thursday 13 Aug 2015 21:29 CEST, Eternal Hope wrote:

> On 13/08/2015 19:12, Cecil Westerhof wrote:
>> I am new to JPA. I have to migrate a JDBC application to JPA. For a
>> certain class there are some extra fields in the table that are not
>> in the class itself.
>
> How do you know they belong to the class if they are not in the
> class? look at the sql, where do these mystery fields come from, are
> they passed in along with the object instance that contains the
> other fields in which case they would need to be contained within
> some other class if it's Java (the horror) are they generated by
> some stored procedure (the horror, the horror) or a trigger (oh the
> horror).

They belong NOT to the class. Extra code is used to fill those table
fields.


> (For example creation time, modification time and
>> user that created the entity.) Is it possible to keep those fields
>> in the table and updated, without putting the values in the class?
>
> Why in [insert deity here]'s name would you want to do that? Is this
> some bastard son (of an application) of an unholy alliance between a
> DBA and an OO designer? Why do you want to avoid adding them to the
> class? Is it because, in your Java brain you feel they don't belong'
> there? If they don't belong in the class then they don't belong in
> the table *unless* they are fields in another class that has some
> sort of containment relationship with your container class?
> (aggregation, composition) in which case they are contained by the
> container class and therefore somehow 'belong' in some 'OO' realty
> in the container.

Well, I only have to change from JDBC to JPA, I did not design the
class and the table. That is probably done a decade (or longer ago).

Personally I find the date fields not that strange. It is good to know
when a record is created, or mutated, but not that useful in the class
itself.


> Trying to map an application to a relational database using a ORM
> framework when some of the fields aren't contained in some way in
> you existential object graph seems a bit like hearding cats ... is
> it even possible, don't know, don't reallyy know JPA but in answer
> to your othr question, as long as you have a driver in your
> classpath then I can't see why you can't use what you want when you
> want to do what you want.
>
> It all just sounds so ... *nasty*

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof