Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32323 > unrolled thread

JPA and extra fields

Back to article view | Back to comp.lang.java.programmer

Contents

  JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-13 20:12 +0200
    Re: JPA and extra fields Eternal Hope <laughingspam99@gmail.com> - 2015-08-13 20:29 +0100
      Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-17 07:40 +0200
    Re: JPA and extra fields Arne Vajhøj <arne@vajhoej.dk> - 2015-08-13 22:30 -0400
      Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-17 08:22 +0200
        Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-17 11:40 +0000
          Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-17 14:36 +0200
            Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-17 18:08 +0000
              Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-17 21:24 +0200
                Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-17 22:47 +0000
                  Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 11:32 +0200
            Re: JPA and extra fields Arne Vajhøj <arne@vajhoej.dk> - 2015-08-17 19:48 -0400
          Re: JPA and extra fields Eternal Hope <laughingspam99@gmail.com> - 2015-08-18 06:25 +0100
            Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-18 10:49 +0000
              Re: JPA and extra fields Eternal Hope <laughingspam99@gmail.com> - 2015-08-19 09:00 +0100
                Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 11:36 +0200
                  Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-19 10:48 +0000
        Re: JPA and extra fields Arne Vajhøj <arne@vajhoej.dk> - 2015-08-17 19:46 -0400
          Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 11:28 +0200
      Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 11:53 +0200
        Re: JPA and extra fields Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-19 10:51 +0000
          Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 13:14 +0200
            Re: JPA and extra fields Cecil Westerhof <Cecil@decebal.nl> - 2015-08-19 14:19 +0200
        Re: JPA and extra fields Arne Vajhøj <arne@vajhoej.dk> - 2015-08-19 19:13 -0400
    Re: JPA and extra fields Silvio <silvio@internet.com> - 2015-08-20 03:49 +0200

Page 2 of 2 — ← Prev page 1 [2]

#32362

On Wed, 19 Aug 2015 11:53:03 +0200, Cecil Westerhof wrote:

> Another possibility would be to write the functions beforeCreate and
> beforeMutate. That would be probably better as my current solution?
>
On the assumption that I've understood the use of these data items, this 
would be my preferred solution.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32363

On Wednesday 19 Aug 2015 12:51 CEST, Martin Gregorie wrote:

> On Wed, 19 Aug 2015 11:53:03 +0200, Cecil Westerhof wrote:
>
>> Another possibility would be to write the functions beforeCreate
>> and beforeMutate. That would be probably better as my current
>> solution?
>>
> On the assumption that I've understood the use of these data items,
> this would be my preferred solution.

I am going to remove the setter function and implement beforeCreate
and beforeMutate. :-)

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

[toc] | [prev] | [next] | [standalone]

#32364

On Wednesday 19 Aug 2015 13:14 CEST, Cecil Westerhof wrote:

> On Wednesday 19 Aug 2015 12:51 CEST, Martin Gregorie wrote:
>
>> On Wed, 19 Aug 2015 11:53:03 +0200, Cecil Westerhof wrote:
>>
>>> Another possibility would be to write the functions beforeCreate
>>> and beforeMutate. That would be probably better as my current
>>> solution?
>>>
>> On the assumption that I've understood the use of these data items,
>> this would be my preferred solution.
>
> I am going to remove the setter function and implement beforeCreate
> and beforeMutate. :-)

It became:
    public void beforeCreate() {
        setMutateInfo();
        dateCreated    = new Date();
        userIDCreation = SecurityUtil.getCurrentUser();
    }

    public void beforeUpdate() {
        setMutateInfo();
        timeMutated    = new Timestamp(new Date().getTime());
        userIDMutation = SecurityUtil.getCurrentUser();
    }

setMutateInfo does things that are needed for beforeCreate and
bedoreUpdate. It is of-course private void.

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

[toc] | [prev] | [next] | [standalone]

#32375

On 8/19/2015 5:53 AM, Cecil Westerhof wrote:
> 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.

If you call a constructor instead of loading from database, then
I would consider that creation time.

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

Or maybe have all other setters update the mutated property?

Arne

[toc] | [prev] | [next] | [standalone]

#32379

On 08/13/2015 08: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?
>

Oh, you have only just gotten your feet wet in ORM land and things start 
to smell nasty already.

I know you already told us you have to go this route but someday not to 
far in the future you will remember me as the guy who told you to turn 
around and run without ever looking back and you will regret not having 
listened.

But in the meantime you will have learned all these neat annotations and 
trigger tricks you used to stay away from for good reasons.

You have my sympathy sir!

Silvio

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web