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: Wed, 19 Aug 2015 11:53:03 +0200
Organization: Decebal Computing
Lines: 48
Message-ID: <87mvxnr4e8.fsf@Equus.decebal.nl>
References: <87zj1v3vnq.fsf@Equus.decebal.nl> <55cd52c4$0$298$14726298@news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="6908"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191P8j6OBGw0K54mRlwohcGUAotOA7kPMM="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:pkEjNHK+YXmt/oRNNIZdyPKhAyg= sha1:jQULHK0gdDTV5lw0eseic721C3I=
X-Homepage: http://www.decebal.nl/
Xref: csiph.com comp.lang.java.programmer:32358

On Friday 14 Aug 2015 04:30 CEST, Arne Vajhøj wrote:

> On 8/13/2015 2:12 PM, 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. (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?

[…]

> 2)
>
> Add the fields to the class but do not expose them in its
> public API. And let them be updated internally.
>
> Possible by mapping fields and either no getter/setter
> or protected.

I do not need the getter fields, but I use setter fields like:
    public void setDatecreated(final Date datecreated) {
        this.datecreated = datecreated;
    }

    public void setUserIDCreated(final String userIDCreated) {
        this.userIDCreatie = userIDCreatie;
    }

    public void setTimeMutated(final Timestamp timeMutated) {
    this.tiimeMutated = timeMutated;
    }

    public void setUserIDMutated(final String userIDMutated) {
        this.userIDMutated = userIDMutated;
    }

The first two could be done in the initialisation of the entity, but
that would give a difference in functionality, so I do not opt for
that.

Another possibility would be to write the functions beforeCreate and
beforeMutate. That would be probably better as my current solution?

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