You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Andrei Tchijov <an...@gmail.com> on 2008/06/17 21:27:58 UTC

field access or property access or both?

I guess I m doing something wrong. Please enlighten me what it is I am  
doing wrong.

I have a class with number of fields.  One of which is boolean.

@Entity
class A {
...
@Basic
boolean		foo;
...
}

OpenJPA doing wonderful job of retrieving  "state" of the objects of  
this class (including 'foo' field).  What puzzles me is that it seems  
to fail to do "opposite".  Somewhere else in my code I have


...
	_tx.begin();
		A a = getA();
		a.foo = !a.foo;
	_tx.commit();
...

It looks similar enough to examples from documentation, but it does  
not work.  I am quite confident that "a" is in "attached" state when I  
am trying to change "condition" field (_em.contans(a ) returns  
true ).  What makes me really puzzled is that if I change code like  
this:


@Entity
class A {
  ...
  @Basic
  boolean		foo;
  ...
  public void setFoo( boolean v ) {
    this.foo = v;
  }
}


...
	_tx.begin();
		A a = getA();
		a.setFoo( ! a.foo );
	_tx.commit();
...

	
To complete picture, I should mention that I am running "outside of  
container" (stand alone application).

Any help will be highly appreciated.

Andrei

Re: field access or property access or both?

Posted by Andrei Tchijov <an...@tchijov.com>.
I choose to go simpler way - made all my persistent fields "protected"  
and provided accessor methods.

One thought - why JPA have not implemented annotation  
"@PersistenceAware" (like JDO does)?  It would allow automatic  
"enhancement" of all classes which deal with persistence.

On Jun 18, 2008, at 17:30 , Patrick Linskey wrote:

> Hi,
>
> Note that with OpenJPA, if you were to explicitly enhance the other  
> classes that access the visible persistent fields directly, things  
> would work.
>
> -Patrick
>
> On Jun 17, 2008, at 3:50 PM, Andrei Tchijov wrote:
>
>> Thanks  Mike. It makes perfect sense.  I assume this is due to the  
>> fact that "@Entity" class gets "enhanced", not all other classes  
>> which happen to use it.
>>
>>
>> On Jun 17, 2008, at 17:16 , Michael Dick wrote:
>>
>>> Hi Andrei,
>>>
>>> You're not alone, I had the same misconception. Field and property  
>>> access
>>> apply to how the persistence provider runtime accesses the state  
>>> of an
>>> entity. Regardless of the access type the client should use the  
>>> entity's
>>> accessor methods.
>>>
>>> From section 2.1 and 2.1.1 of the JPA specification
>>> 2.1
>>> . . .
>>> The persistent state of an entity is represented by instance  
>>> variables,
>>> which may correspond to Java-
>>> Beans properties. An instance variable may be directly accessed  
>>> only from
>>> within the methods of the
>>> entity by the entity instance itself.* Instance variables must not  
>>> be
>>> accessed by clients of the entity. The
>>> state of the entity is available to clients only through the  
>>> entity's
>>> accessor methods (getter/setter methods)
>>> or other business methods*. Instance variables must be private,  
>>> protected,
>>> or package visibility.
>>>
>>> 2.1.1 Persistent Fields and Properties
>>> The persistent state of an entity is accessed by the persistence  
>>> provider
>>> runtime[1] either via JavaBeans
>>> style property accessors or via instance variables. A single  
>>> access type
>>> (field or property access) applies
>>> to an entity hierarchy. When annotations are used, the placement  
>>> of the
>>> mapping annotations on either
>>> the persistent fields or persistent properties of the entity class  
>>> specifies
>>> the access type as being either
>>> field- or property-based access respectively.
>>> . . .
>>> [1] The term "persistence provider runtime" refers to the runtime
>>> environment of the persistence implementation. In Java EE  
>>> environments,
>>> this may be the Java EE container or a third-party persistence  
>>> provider
>>> implementation integrated with it.
>>> . . .
>>>
>>> So technically the second option is the more correct way to set a  
>>> state
>>> variable.
>>>
>>> Hope this helps,
>>>
>>> -mike
>>>
>>>
>>> On Tue, Jun 17, 2008 at 2:27 PM, Andrei Tchijov <andrei.tchijov@gmail.com 
>>> >
>>> wrote:
>>>
>>>> I guess I m doing something wrong. Please enlighten me what it is  
>>>> I am
>>>> doing wrong.
>>>>
>>>> I have a class with number of fields.  One of which is boolean.
>>>>
>>>> @Entity
>>>> class A {
>>>> ...
>>>> @Basic
>>>> boolean         foo;
>>>> ...
>>>> }
>>>>
>>>> OpenJPA doing wonderful job of retrieving  "state" of the objects  
>>>> of this
>>>> class (including 'foo' field).  What puzzles me is that it seems  
>>>> to fail to
>>>> do "opposite".  Somewhere else in my code I have
>>>>
>>>>
>>>> ...
>>>>     _tx.begin();
>>>>             A a = getA();
>>>>             a.foo = !a.foo;
>>>>     _tx.commit();
>>>> ...
>>>>
>>>> It looks similar enough to examples from documentation, but it  
>>>> does not
>>>> work.  I am quite confident that "a" is in "attached" state when  
>>>> I am trying
>>>> to change "condition" field (_em.contans(a ) returns true ).   
>>>> What makes me
>>>> really puzzled is that if I change code like this:
>>>>
>>>>
>>>> @Entity
>>>> class A {
>>>> ...
>>>> @Basic
>>>> boolean                foo;
>>>> ...
>>>> public void setFoo( boolean v ) {
>>>> this.foo = v;
>>>> }
>>>> }
>>>>
>>>>
>>>> ...
>>>>     _tx.begin();
>>>>             A a = getA();
>>>>             a.setFoo( ! a.foo );
>>>>     _tx.commit();
>>>> ...
>>>>
>>>>
>>>> To complete picture, I should mention that I am running "outside of
>>>> container" (stand alone application).
>>>>
>>>> Any help will be highly appreciated.
>>>>
>>>> Andrei
>>>>
>>
>
> -- 
> Patrick Linskey
> 202 669 5907
>


Re: field access or property access or both?

Posted by Patrick Linskey <pl...@gmail.com>.
Hi,

Note that with OpenJPA, if you were to explicitly enhance the other  
classes that access the visible persistent fields directly, things  
would work.

-Patrick

On Jun 17, 2008, at 3:50 PM, Andrei Tchijov wrote:

> Thanks  Mike. It makes perfect sense.  I assume this is due to the  
> fact that "@Entity" class gets "enhanced", not all other classes  
> which happen to use it.
>
>
> On Jun 17, 2008, at 17:16 , Michael Dick wrote:
>
>> Hi Andrei,
>>
>> You're not alone, I had the same misconception. Field and property  
>> access
>> apply to how the persistence provider runtime accesses the state of  
>> an
>> entity. Regardless of the access type the client should use the  
>> entity's
>> accessor methods.
>>
>> From section 2.1 and 2.1.1 of the JPA specification
>> 2.1
>> . . .
>> The persistent state of an entity is represented by instance  
>> variables,
>> which may correspond to Java-
>> Beans properties. An instance variable may be directly accessed  
>> only from
>> within the methods of the
>> entity by the entity instance itself.* Instance variables must not be
>> accessed by clients of the entity. The
>> state of the entity is available to clients only through the entity's
>> accessor methods (getter/setter methods)
>> or other business methods*. Instance variables must be private,  
>> protected,
>> or package visibility.
>>
>> 2.1.1 Persistent Fields and Properties
>> The persistent state of an entity is accessed by the persistence  
>> provider
>> runtime[1] either via JavaBeans
>> style property accessors or via instance variables. A single access  
>> type
>> (field or property access) applies
>> to an entity hierarchy. When annotations are used, the placement of  
>> the
>> mapping annotations on either
>> the persistent fields or persistent properties of the entity class  
>> specifies
>> the access type as being either
>> field- or property-based access respectively.
>> . . .
>> [1] The term "persistence provider runtime" refers to the runtime
>> environment of the persistence implementation. In Java EE  
>> environments,
>> this may be the Java EE container or a third-party persistence  
>> provider
>> implementation integrated with it.
>> . . .
>>
>> So technically the second option is the more correct way to set a  
>> state
>> variable.
>>
>> Hope this helps,
>>
>> -mike
>>
>>
>> On Tue, Jun 17, 2008 at 2:27 PM, Andrei Tchijov <andrei.tchijov@gmail.com 
>> >
>> wrote:
>>
>>> I guess I m doing something wrong. Please enlighten me what it is  
>>> I am
>>> doing wrong.
>>>
>>> I have a class with number of fields.  One of which is boolean.
>>>
>>> @Entity
>>> class A {
>>> ...
>>> @Basic
>>> boolean         foo;
>>> ...
>>> }
>>>
>>> OpenJPA doing wonderful job of retrieving  "state" of the objects  
>>> of this
>>> class (including 'foo' field).  What puzzles me is that it seems  
>>> to fail to
>>> do "opposite".  Somewhere else in my code I have
>>>
>>>
>>> ...
>>>      _tx.begin();
>>>              A a = getA();
>>>              a.foo = !a.foo;
>>>      _tx.commit();
>>> ...
>>>
>>> It looks similar enough to examples from documentation, but it  
>>> does not
>>> work.  I am quite confident that "a" is in "attached" state when I  
>>> am trying
>>> to change "condition" field (_em.contans(a ) returns true ).  What  
>>> makes me
>>> really puzzled is that if I change code like this:
>>>
>>>
>>> @Entity
>>> class A {
>>> ...
>>> @Basic
>>> boolean                foo;
>>> ...
>>> public void setFoo( boolean v ) {
>>> this.foo = v;
>>> }
>>> }
>>>
>>>
>>> ...
>>>      _tx.begin();
>>>              A a = getA();
>>>              a.setFoo( ! a.foo );
>>>      _tx.commit();
>>> ...
>>>
>>>
>>> To complete picture, I should mention that I am running "outside of
>>> container" (stand alone application).
>>>
>>> Any help will be highly appreciated.
>>>
>>> Andrei
>>>
>

-- 
Patrick Linskey
202 669 5907


Re: field access or property access or both?

Posted by Andrei Tchijov <an...@tchijov.com>.
Thanks  Mike. It makes perfect sense.  I assume this is due to the  
fact that "@Entity" class gets "enhanced", not all other classes which  
happen to use it.


On Jun 17, 2008, at 17:16 , Michael Dick wrote:

> Hi Andrei,
>
> You're not alone, I had the same misconception. Field and property  
> access
> apply to how the persistence provider runtime accesses the state of an
> entity. Regardless of the access type the client should use the  
> entity's
> accessor methods.
>
> From section 2.1 and 2.1.1 of the JPA specification
> 2.1
> . . .
> The persistent state of an entity is represented by instance  
> variables,
> which may correspond to Java-
> Beans properties. An instance variable may be directly accessed only  
> from
> within the methods of the
> entity by the entity instance itself.* Instance variables must not be
> accessed by clients of the entity. The
> state of the entity is available to clients only through the entity's
> accessor methods (getter/setter methods)
> or other business methods*. Instance variables must be private,  
> protected,
> or package visibility.
>
> 2.1.1 Persistent Fields and Properties
> The persistent state of an entity is accessed by the persistence  
> provider
> runtime[1] either via JavaBeans
> style property accessors or via instance variables. A single access  
> type
> (field or property access) applies
> to an entity hierarchy. When annotations are used, the placement of  
> the
> mapping annotations on either
> the persistent fields or persistent properties of the entity class  
> specifies
> the access type as being either
> field- or property-based access respectively.
> . . .
> [1] The term "persistence provider runtime" refers to the runtime
> environment of the persistence implementation. In Java EE  
> environments,
> this may be the Java EE container or a third-party persistence  
> provider
> implementation integrated with it.
> . . .
>
> So technically the second option is the more correct way to set a  
> state
> variable.
>
> Hope this helps,
>
> -mike
>
>
> On Tue, Jun 17, 2008 at 2:27 PM, Andrei Tchijov <andrei.tchijov@gmail.com 
> >
> wrote:
>
>> I guess I m doing something wrong. Please enlighten me what it is I  
>> am
>> doing wrong.
>>
>> I have a class with number of fields.  One of which is boolean.
>>
>> @Entity
>> class A {
>> ...
>> @Basic
>> boolean         foo;
>> ...
>> }
>>
>> OpenJPA doing wonderful job of retrieving  "state" of the objects  
>> of this
>> class (including 'foo' field).  What puzzles me is that it seems to  
>> fail to
>> do "opposite".  Somewhere else in my code I have
>>
>>
>> ...
>>       _tx.begin();
>>               A a = getA();
>>               a.foo = !a.foo;
>>       _tx.commit();
>> ...
>>
>> It looks similar enough to examples from documentation, but it does  
>> not
>> work.  I am quite confident that "a" is in "attached" state when I  
>> am trying
>> to change "condition" field (_em.contans(a ) returns true ).  What  
>> makes me
>> really puzzled is that if I change code like this:
>>
>>
>> @Entity
>> class A {
>> ...
>> @Basic
>> boolean                foo;
>> ...
>> public void setFoo( boolean v ) {
>>  this.foo = v;
>> }
>> }
>>
>>
>> ...
>>       _tx.begin();
>>               A a = getA();
>>               a.setFoo( ! a.foo );
>>       _tx.commit();
>> ...
>>
>>
>> To complete picture, I should mention that I am running "outside of
>> container" (stand alone application).
>>
>> Any help will be highly appreciated.
>>
>> Andrei
>>


Re: field access or property access or both?

Posted by Michael Dick <mi...@apache.org>.
Hi Andrei,

You're not alone, I had the same misconception. Field and property access
apply to how the persistence provider runtime accesses the state of an
entity. Regardless of the access type the client should use the entity's
accessor methods.

>From section 2.1 and 2.1.1 of the JPA specification
2.1
. . .
The persistent state of an entity is represented by instance variables,
which may correspond to Java-
Beans properties. An instance variable may be directly accessed only from
within the methods of the
entity by the entity instance itself.* Instance variables must not be
accessed by clients of the entity. The
state of the entity is available to clients only through the entity's
accessor methods (getter/setter methods)
or other business methods*. Instance variables must be private, protected,
or package visibility.

2.1.1 Persistent Fields and Properties
The persistent state of an entity is accessed by the persistence provider
runtime[1] either via JavaBeans
style property accessors or via instance variables. A single access type
(field or property access) applies
to an entity hierarchy. When annotations are used, the placement of the
mapping annotations on either
the persistent fields or persistent properties of the entity class specifies
the access type as being either
field- or property-based access respectively.
 . . .
[1] The term "persistence provider runtime" refers to the runtime
environment of the persistence implementation. In Java EE environments,
this may be the Java EE container or a third-party persistence provider
implementation integrated with it.
. . .

So technically the second option is the more correct way to set a state
variable.

Hope this helps,

-mike


On Tue, Jun 17, 2008 at 2:27 PM, Andrei Tchijov <an...@gmail.com>
wrote:

> I guess I m doing something wrong. Please enlighten me what it is I am
> doing wrong.
>
> I have a class with number of fields.  One of which is boolean.
>
> @Entity
> class A {
> ...
> @Basic
> boolean         foo;
> ...
> }
>
> OpenJPA doing wonderful job of retrieving  "state" of the objects of this
> class (including 'foo' field).  What puzzles me is that it seems to fail to
> do "opposite".  Somewhere else in my code I have
>
>
> ...
>        _tx.begin();
>                A a = getA();
>                a.foo = !a.foo;
>        _tx.commit();
> ...
>
> It looks similar enough to examples from documentation, but it does not
> work.  I am quite confident that "a" is in "attached" state when I am trying
> to change "condition" field (_em.contans(a ) returns true ).  What makes me
> really puzzled is that if I change code like this:
>
>
> @Entity
> class A {
>  ...
>  @Basic
>  boolean                foo;
>  ...
>  public void setFoo( boolean v ) {
>   this.foo = v;
>  }
> }
>
>
> ...
>        _tx.begin();
>                A a = getA();
>                a.setFoo( ! a.foo );
>        _tx.commit();
> ...
>
>
> To complete picture, I should mention that I am running "outside of
> container" (stand alone application).
>
> Any help will be highly appreciated.
>
> Andrei
>