You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2008/01/01 12:26:24 UTC
Re: Make dirty of detached objects?
> Therefore, I'd like to kindly ask for a spec change:
> JDOHelper.makeDirty(...) and the corresponding
> PersistenceCapable.jdoMakeDirty(...) should work with detached objects
> as well.
+1 but
"JDOHelper.makeDirty(...) and the corresponding
PersistenceCapable.jdoMakeDirty(...) should work with detached objects where
the specified field is loaded in the detached object"
since if the field is not loaded it makes no sense to mark it as dirty yet not
have a new value ;-)
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: Make dirty of detached objects? Spec Chapter 23
Posted by Andy Jefferson <an...@jpox.org>.
> 23.17 Generated methods in least-derived PersistenceCapable class
> public final void jdoMakeDirty (String fieldName);
Adding on support for making fields of detached objects dirty means that this
signature will likely have to change :-
1. field names are only known about in the "jdoFieldNames" String[] of each
class. This doesn't matter with non-detached objects since the field name
goes straight across to the StateManager. For detached objects a translation
from field name to field number needs to happen to update the right part of
jdoDetachedState.
2. Some classes in an inheritance tree can be detachable and some not (same
issue as jdoIsDetached signature change in JDO-459)
With these in mind, for chapter 23 we can have the following
public void jdoMakeDirty(String fieldName)
{
if (jdoStateManager != null)
jdoStateManager.makeDirty(this, fieldName);
}
for non-detachable root classes, and
public void jdoMakeDirty(String fieldName)
{
if (jdoStateManager != null)
jdoStateManager.makeDirty(this, fieldName);
if (jdoIsDetached())
{
if (fieldName != null && fieldName.indexOf('.') >= 0)
{
String className = fieldName.substring(0,
fieldName.lastIndexOf('.'));
if (className.equals(this.getClass().getName())) {
for (int i = 0; i < jdoFieldNames.length; i++) {
if (jdoFieldNames[i].equals(fieldName)) {
if (((BitSet) jdoDetachedState[2]).get(i +
jdoInheritedFieldCount)) {
((BitSet) jdoDetachedState[3]).set(i +
jdoInheritedFieldCount);
return;
}
throw new JDODetachedFieldAccessException("You have just
attempted to access a field/property that hasn't been detached. Please detach
it first before performing this operation");
}
}
}
super.jdoMakeDirty(fieldName);
}
}
}
for detachable classes
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: jdoMakeDirty
Posted by Andy Jefferson <an...@jpox.org>.
> void jdoMakeDirty (int fieldNumber);
What is this "PersistenceCapable.jdoMakeDirty(int)" method about ? It seems to
be present in the JDO2.0 spec also yet the API doesn't have it. How does the
user know the field "number" ? Typo ?
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: Make dirty of detached objects?
Posted by Craig L Russell <Cr...@Sun.COM>.
Here's the proposed spec change:
<proposed>
void jdoMakeDirty (String fieldName);
void jdoMakeDirty (int fieldNumber);
A7.2-1 [
These methods mark the specified field dirty so that its values will
be modified in the datastore when the transaction in which the
instance is modified is committed. The fieldName is the name of the
field to be marked as dirty, optionally including the fully qualified
package name and class name of the field]. A7.2-2 [This method
returns with no effect if the instance is not detached or managed by
a StateManager.] This method has the same effect on the life cycle
state of the instance as changing a managed field would. The
fieldNumber parameter is the internal field number assigned during
class enhancement.
If the instance is detached and the field has not been loaded,
JDODetachedFieldAccessException is thrown.
</proposed>
On Jan 2, 2008, at 4:06 AM, Marco Schulze wrote:
> Andy Jefferson wrote:
>>> Therefore, I'd like to kindly ask for a spec change:
>>> JDOHelper.makeDirty(...) and the corresponding
>>> PersistenceCapable.jdoMakeDirty(...) should work with detached
>>> objects
>>> as well.
>>>
>>
>> +1 but
>> "JDOHelper.makeDirty(...) and the corresponding
>> PersistenceCapable.jdoMakeDirty(...) should work with detached
>> objects where
>> the specified field is loaded in the detached object"
>> since if the field is not loaded it makes no sense to mark it as
>> dirty yet not
>> have a new value ;-)
>>
>
> I totally agree! Of course, makeDirty/jdoMakeDirty only makes sense
> for fields that have been loaded in the detached object.
>
> Will the method throw a javax.jdo.JDODetachedFieldAccessException
> or silently ignore non-loaded fields in detached objects?
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Make dirty of detached objects?
Posted by Marco Schulze <Ma...@NightLabs.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Craig L Russell wrote:
> Hi Marco,
>
> On Jan 2, 2008, at 11:03 AM, Marco Schulze wrote:
>
>> Craig L Russell wrote:
>>> This might be an academic discussion. But what fun. ;-)
>>>
>>> The main reason for jdoMakeDirty is to mark fields that cannot mark
>>> themselves as dirty; that is array types that by implementation cannot
>>> be extended or enhanced. If an array type field has a non-null value
>>> that needs to be marked dirty, then the field is loaded. And if the
>>> value is loaded, jdoMakeDirty won't throw an exception.
>>>
>>> For consistency, though, I'd have to vote for jdoMakeDirty throwing an
>>> exception on an unloaded field.
>>>
>>> Craig
>>
>> Hello Craig,
>>
>> first, I'd like to agree that throwing an exception is the better
>> choice, since it provides additional information (was the field
>> present?) and applications can choose to catch it, if they want to have
>> it ignored.
>
> Right.
>>
>> Additionally, I'd like to mention that we need it in a multi-datastore
>> environment (i.e. replication) and therefore want to use it for all
>> fields (not only arrays). Otherwise existing records in the destination
>> datastore wouldn't be updated (since no field was changed between
>> detaching attaching).
>
> Right. There is no good alternative to marking fields as dirty because
> reflective access also bypasses the get/set methods.
>
>>
>> Please allow me to bring up my feature request for this replication use
>> case again:
>>> Every datastore should
>>> have a unique identifier and a detached object should know from which
>>> datastore it has been detached. Hence, when attaching it, the JDO
>>> implementation could check whether the datastore is the same and if it
>>> is not, treat every field as dirty.
>> This datastore-identifier should be an optional feature, of course,
>> since many people work with solely one datastore.
>
> For now, your workaround will have to suffice.
>
> Best,
>
> Craig
>>
>> Best regards, Marco :-)
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
Hello Craig,
thanks a lot for your response and sorry for my late reaction.
I'm happy that you agreed on the first points and I can live just fine
with "makeDirty" as a workaround for replication. The datastore-id was
just a suggestion and I'm sure there will be more JDO releases in the
future ;-)
Best regards, Marco :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHj3wAOn48nLzkjcIRAiDnAJ9ueV4tyVxv+DfLuBHGc8ET1aaPcwCgh2eu
QCZ8sFPZX6F4tcgF1SBv6lI=
=DJCJ
-----END PGP SIGNATURE-----
Re: Make dirty of detached objects?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Marco,
On Jan 2, 2008, at 11:03 AM, Marco Schulze wrote:
> Craig L Russell wrote:
>> This might be an academic discussion. But what fun. ;-)
>>
>> The main reason for jdoMakeDirty is to mark fields that cannot mark
>> themselves as dirty; that is array types that by implementation
>> cannot
>> be extended or enhanced. If an array type field has a non-null value
>> that needs to be marked dirty, then the field is loaded. And if the
>> value is loaded, jdoMakeDirty won't throw an exception.
>>
>> For consistency, though, I'd have to vote for jdoMakeDirty
>> throwing an
>> exception on an unloaded field.
>>
>> Craig
>
> Hello Craig,
>
> first, I'd like to agree that throwing an exception is the better
> choice, since it provides additional information (was the field
> present?) and applications can choose to catch it, if they want to
> have
> it ignored.
Right.
>
> Additionally, I'd like to mention that we need it in a multi-datastore
> environment (i.e. replication) and therefore want to use it for all
> fields (not only arrays). Otherwise existing records in the
> destination
> datastore wouldn't be updated (since no field was changed between
> detaching attaching).
Right. There is no good alternative to marking fields as dirty
because reflective access also bypasses the get/set methods.
>
> Please allow me to bring up my feature request for this replication
> use
> case again:
>> Every datastore should
>> have a unique identifier and a detached object should know from which
>> datastore it has been detached. Hence, when attaching it, the JDO
>> implementation could check whether the datastore is the same and
>> if it
>> is not, treat every field as dirty.
> This datastore-identifier should be an optional feature, of course,
> since many people work with solely one datastore.
For now, your workaround will have to suffice.
Best,
Craig
>
> Best regards, Marco :-)
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Make dirty of detached objects?
Posted by Marco Schulze <ma...@jfire.org>.
Craig L Russell wrote:
> This might be an academic discussion. But what fun. ;-)
>
> The main reason for jdoMakeDirty is to mark fields that cannot mark
> themselves as dirty; that is array types that by implementation cannot
> be extended or enhanced. If an array type field has a non-null value
> that needs to be marked dirty, then the field is loaded. And if the
> value is loaded, jdoMakeDirty won't throw an exception.
>
> For consistency, though, I'd have to vote for jdoMakeDirty throwing an
> exception on an unloaded field.
>
> Craig
Hello Craig,
first, I'd like to agree that throwing an exception is the better
choice, since it provides additional information (was the field
present?) and applications can choose to catch it, if they want to have
it ignored.
Additionally, I'd like to mention that we need it in a multi-datastore
environment (i.e. replication) and therefore want to use it for all
fields (not only arrays). Otherwise existing records in the destination
datastore wouldn't be updated (since no field was changed between
detaching attaching).
Please allow me to bring up my feature request for this replication use
case again:
> Every datastore should
> have a unique identifier and a detached object should know from which
> datastore it has been detached. Hence, when attaching it, the JDO
> implementation could check whether the datastore is the same and if it
> is not, treat every field as dirty.
This datastore-identifier should be an optional feature, of course,
since many people work with solely one datastore.
Best regards, Marco :-)
Re: Make dirty of detached objects?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andy,
On Jan 2, 2008, at 8:44 AM, Andy Jefferson wrote:
>> Will the method throw a javax.jdo.JDODetachedFieldAccessException
>> or silently ignore non-loaded fields in detached objects?
>
> I'd just expect a silent ignore.
> The only place a JDODetachedFieldAccessException should be thrown
> is in any
> actual access of the field (jdoGetXXX with persistent fields, or
> getXXX with
> persistent properties)
This might be an academic discussion. But what fun. ;-)
The main reason for jdoMakeDirty is to mark fields that cannot mark
themselves as dirty; that is array types that by implementation
cannot be extended or enhanced. If an array type field has a non-null
value that needs to be marked dirty, then the field is loaded. And if
the value is loaded, jdoMakeDirty won't throw an exception.
For consistency, though, I'd have to vote for jdoMakeDirty throwing
an exception on an unloaded field.
Craig
>
>
> --
> Andy (Java Persistent Objects - http://www.jpox.org)
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Make dirty of detached objects?
Posted by Andy Jefferson <an...@jpox.org>.
> Will the method throw a javax.jdo.JDODetachedFieldAccessException
> or silently ignore non-loaded fields in detached objects?
I'd just expect a silent ignore.
The only place a JDODetachedFieldAccessException should be thrown is in any
actual access of the field (jdoGetXXX with persistent fields, or getXXX with
persistent properties)
--
Andy (Java Persistent Objects - http://www.jpox.org)
Re: Make dirty of detached objects?
Posted by Marco Schulze <ma...@jfire.org>.
Andy Jefferson wrote:
>> Therefore, I'd like to kindly ask for a spec change:
>> JDOHelper.makeDirty(...) and the corresponding
>> PersistenceCapable.jdoMakeDirty(...) should work with detached objects
>> as well.
>>
>
> +1 but
> "JDOHelper.makeDirty(...) and the corresponding
> PersistenceCapable.jdoMakeDirty(...) should work with detached objects where
> the specified field is loaded in the detached object"
> since if the field is not loaded it makes no sense to mark it as dirty yet not
> have a new value ;-)
>
I totally agree! Of course, makeDirty/jdoMakeDirty only makes sense
for fields that have been loaded in the detached object.
Will the method throw a javax.jdo.JDODetachedFieldAccessException
or silently ignore non-loaded fields in detached objects?