Grails › Grails User (Old Archive)

GORM setting access="field"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

basejump (Josh)

GORM setting access="field"

2 questions

1. is there a "grails" way to set this to field for a class or all classes?
2. are there any negative implications to setting it to field instead of the default property?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

basejump (Josh)

Re: GORM setting access="field"

I'm stuck on this one and even if it do a hibernate.cfg file its not picking up that I want default-access="field"
I would like to override some setters to set some other fields when its a new object but the setters get called when hibernate loads the object

Any one else doing setting access to field in Gorm? Is it a bad thing to do with Gorm?

On Mar 14, 2010, at 7:46 PM, basejump wrote:

> 2 questions
>
> 1. is there a "grails" way to set this to field for a class or all classes?
> 2. are there any negative implications to setting it to field instead of the default property?
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Bob Brown

Re: GORM setting access="field"

Maybe this will help?

http://colinharrington.net/blog/2009/01/gorm-override-a-setter-on-a-grails-d
omain/

Bob

> -----Original Message-----
> From: basejump [mailto:[hidden email]]
> Sent: Tuesday, 16 March 2010 9:52 AM
> To: [hidden email]
> Subject: [grails-user] Re: GORM setting access="field"
>
> I'm stuck on this one and even if it do a hibernate.cfg file its not
picking up
> that I want default-access="field"
> I would like to override some setters to set some other fields when its a
new
> object but the setters get called when hibernate loads the object
>
> Any one else doing setting access to field in Gorm? Is it a bad thing to
do with
> Gorm?
>
> On Mar 14, 2010, at 7:46 PM, basejump wrote:
>
> > 2 questions
> >
> > 1. is there a "grails" way to set this to field for a class or all
classes?
> > 2. are there any negative implications to setting it to field instead of
the
> default property?
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

basejump (Josh)

Re: GORM setting access="field"

Thanks. I got how to overide setters

The blog you attached has an unanswered comment at the very end that hits what I am running into

His example was

String password
void setPassword(String pw) {
password = getHash(pw,salt)
}

when the object loads from Hibernate by default it will call the setter and rehash the password

When we used hibernate/jpa we would set access=field which told hibernate to set the value on the field and not the setter when it loads from the database.

I am wondering if its a good idea to set field access or if anyone else has done it and run into problems

On Mar 15, 2010, at 7:26 PM, Bob Brown wrote:

Maybe this will help?

http://colinharrington.net/blog/2009/01/gorm-override-a-setter-on-a-grails-d
omain/

Bob

-----Original Message-----
From: basejump [mailto:[hidden email]]
Sent: Tuesday, 16 March 2010 9:52 AM
To: [hidden email]
Subject: [grails-user] Re: GORM setting access="field"

I'm stuck on this one and even if it do a hibernate.cfg file its not
picking up
that I want default-access="field"
I would like to override some setters to set some other fields when its a
new
object but the setters get called when hibernate loads the object

Any one else doing setting access to field in Gorm? Is it a bad thing to
do with
Gorm?

On Mar 14, 2010, at 7:46 PM, basejump wrote:

2 questions

1. is there a "grails" way to set this to field for a class or all
classes?
2. are there any negative implications to setting it to field instead of
the
default property?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

burtbeckwith

Re: GORM setting access="field"

I got it working but I have no idea what side effects there might be to using this approach, so ymmv.

The trick is to use a custom Configuration class, and it should extend either GrailsAnnotationConfiguration (if you're also using annotated JPA classes) or DefaultGrailsDomainConfiguration if you're just using Groovy domain classes. Register your custom configuration class in DataSource.groovy:

dataSource {
configClass = com.yourco.yourapp.FieldAccessHibernateConfiguration
pooled = true
driverClassName = ...
...
}

You need to write the class in Java due to a compile issue related to method visibility:

package com.yourco.yourapp;

import java.util.Collection;
import java.util.Iterator;

import org.codehaus.groovy.grails.orm.hibernate.cfg.DefaultGrailsDomainConfiguration;
import org.hibernate.MappingException;
import org.hibernate.mapping.PersistentClass;
import org.hibernate.mapping.Property;

public class FieldAccessHibernateConfiguration extends DefaultGrailsDomainConfiguration {

private static final long serialVersionUID = 1;

private boolean _alreadyProcessed;

@SuppressWarnings("unchecked")
@Override
protected void secondPassCompile() throws MappingException {
super.secondPassCompile();

if (_alreadyProcessed) {
return;
}

for (PersistentClass pc : (Collection<PersistentClass>)classes.values()) {

// pc.getIdentifierProperty().setPropertyAccessorName("field");

for (Iterator iter = pc.getPropertyIterator(); iter.hasNext(); ) {
Property property = (Property)iter.next();
property.setPropertyAccessorName("field");
}
}

_alreadyProcessed = true;
}
}

I didn't test setting the id to field access so I left that commented out; it's a special case and doesn't appear in the property iterator.

Burt

> Thanks. I got how to overide setters
> The blog you attached has an unanswered comment at the very end that hits what I am running into
> His example was
> String password
> void setPassword(String pw) {
> password = getHash(pw,salt)
> }
>
> when the object loads from Hibernate by default it will call the setter and rehash the password
>
> When we used hibernate/jpa we would set access=field which told hibernate to set the value on the field and not the setter when it loads from the database.
>
> I am wondering if its a good idea to set field access or if anyone else has done it and run into problems
>
> On Mar 15, 2010, at 7:26 PM, Bob Brown wrote:
>
> > Maybe this will help?
> >
> > http://colinharrington.net/blog/2009/01/gorm-override-a-setter-on-a-grails-d
> > omain/
> >
> > Bob
> >
> >
> >> -----Original Message-----
> >> From: basejump [mailto:[hidden email]]
> >> Sent: Tuesday, 16 March 2010 9:52 AM
> >> To: [hidden email]
> >> Subject: [grails-user] Re: GORM setting access="field"
> >>
> >> I'm stuck on this one and even if it do a hibernate.cfg file its not
> > picking up
> >> that I want default-access="field"
> >> I would like to override some setters to set some other fields when its a
> > new
> >> object but the setters get called when hibernate loads the object
> >>
> >> Any one else doing setting access to field in Gorm? Is it a bad thing to
> > do with
> >> Gorm?
> >>
> >> On Mar 14, 2010, at 7:46 PM, basejump wrote:
> >>
> >>> 2 questions
> >>>
> >>> 1. is there a "grails" way to set this to field for a class or all
> > classes?
> >>> 2. are there any negative implications to setting it to field instead of
> > the
> >> default property?
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>

signature.asc (204 bytes) Download Attachment

basejump (Josh)

Re: GORM setting access="field"

Brilliant. Thanks Burt.
I'll try it out.

On Mar 15, 2010, at 11:33 PM, Burt Beckwith wrote:

> I got it working but I have no idea what side effects there might be to using this approach, so ymmv.
>
> The trick is to use a custom Configuration class, and it should extend either GrailsAnnotationConfiguration (if you're also using annotated JPA classes) or DefaultGrailsDomainConfiguration if you're just using Groovy domain classes. Register your custom configuration class in DataSource.groovy:
>
> dataSource {
> configClass = com.yourco.yourapp.FieldAccessHibernateConfiguration
> pooled = true
> driverClassName = ...
> ...
> }
>
> You need to write the class in Java due to a compile issue related to method visibility:
>
> package com.yourco.yourapp;
>
> import java.util.Collection;
> import java.util.Iterator;
>
> import org.codehaus.groovy.grails.orm.hibernate.cfg.DefaultGrailsDomainConfiguration;
> import org.hibernate.MappingException;
> import org.hibernate.mapping.PersistentClass;
> import org.hibernate.mapping.Property;
>
> public class FieldAccessHibernateConfiguration extends DefaultGrailsDomainConfiguration {
>
> private static final long serialVersionUID = 1;
>
> private boolean _alreadyProcessed;
>
> @SuppressWarnings("unchecked")
> @Override
> protected void secondPassCompile() throws MappingException {
> super.secondPassCompile();
>
> if (_alreadyProcessed) {
> return;
> }
>
> for (PersistentClass pc : (Collection<PersistentClass>)classes.values()) {
>
> // pc.getIdentifierProperty().setPropertyAccessorName("field");
>
> for (Iterator iter = pc.getPropertyIterator(); iter.hasNext(); ) {
> Property property = (Property)iter.next();
> property.setPropertyAccessorName("field");
> }
> }
>
> _alreadyProcessed = true;
> }
> }
>
> I didn't test setting the id to field access so I left that commented out; it's a special case and doesn't appear in the property iterator.
>
> Burt
>
>> Thanks. I got how to overide setters
>> The blog you attached has an unanswered comment at the very end that hits what I am running into
>> His example was
>> String password
>> void setPassword(String pw) {
>> password = getHash(pw,salt)
>> }
>>
>> when the object loads from Hibernate by default it will call the setter and rehash the password
>>
>> When we used hibernate/jpa we would set access=field which told hibernate to set the value on the field and not the setter when it loads from the database.
>>
>> I am wondering if its a good idea to set field access or if anyone else has done it and run into problems
>>
>> On Mar 15, 2010, at 7:26 PM, Bob Brown wrote:
>>
>>> Maybe this will help?
>>>
>>> http://colinharrington.net/blog/2009/01/gorm-override-a-setter-on-a-grails-d
>>> omain/
>>>
>>> Bob
>>>
>>>
>>>> -----Original Message-----
>>>> From: basejump [mailto:[hidden email]]
>>>> Sent: Tuesday, 16 March 2010 9:52 AM
>>>> To: [hidden email]
>>>> Subject: [grails-user] Re: GORM setting access="field"
>>>>
>>>> I'm stuck on this one and even if it do a hibernate.cfg file its not
>>> picking up
>>>> that I want default-access="field"
>>>> I would like to override some setters to set some other fields when its a
>>> new
>>>> object but the setters get called when hibernate loads the object
>>>>
>>>> Any one else doing setting access to field in Gorm? Is it a bad thing to
>>> do with
>>>> Gorm?
>>>>
>>>> On Mar 14, 2010, at 7:46 PM, basejump wrote:
>>>>
>>>>> 2 questions
>>>>>
>>>>> 1. is there a "grails" way to set this to field for a class or all
>>> classes?
>>>>> 2. are there any negative implications to setting it to field instead of
>>> the
>>>> default property?
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

hgorni

Re: GORM setting access="field"

Thank you so very much for this solution. You've saved my life. I have been searching for a solution like this for days.

My domain classes contain JUNG graphs references. JUNG's API doesn't officially support persistence for these classes, therefore, whenever I read read my domain class from the DB (the graph is in a blob field), there's something in JUNG's implementation that changes the binary checksum during the de-serialization, making the instance dirty and, therefore triggering optimistic locking. This is a serious problem for my app because in case someone is editing a record for a given instance and another person opens another session of the app and lists all the instances (the one being edited inclusive), the person editing the opened instance will get an optimistic locking exception and lose his work.

With your solution I just set the graph properties to optimisticLocked=false and everything works great. I have followed your solution and changed the property loop bit in the code following the suggestion by Jean-Noël Rivasseau on this other thread:

http://grails.1312388.n4.nabble.com/Disabling-optimistic-locking-for-only-certain-properties-td1839018.html

if (property.getName().equals("graph field name")) {
property.setOptimisticLocked(false);
}

However, it seems the beforeUpdate/afterUpdate events are still being executed even if I don't get the optimistic locking failure anymore. This only affets the lastUpdated field which keeps being updated whenever I do a DomainClass.list() or DomainClass.get(id). But that's ok, I'm not using that field for now anyways. If you have any idea though about why this happens or where would be a good point to debug it, I would really appreciate.

Thans again!