| cbeams 2007-08-09, 1:11 am |
| Craig,
Thanks for the response. A few clarifications below:
- Chris
On Aug 8, 2007, at 5:35 PM, Craig L Russell wrote:
> Hi Chris,
>
> On Aug 8, 2007, at 4:59 PM, cbeams wrote:
>
>
> The default for a field that normally persistent should be
> persistent. What happens if you leave off the persistenceModifier?
> JPOX should default it to PERSISTENT.
Right... however, as "MyObject" is a custom type of my own creation
and implicitly subclassing only java.lang.Object, it is NOT by
default persistent (see http://www.jpox.org/docs/1_2/types.html).
This means that I must both specify @Persistent AND pass a
"persistenceModifier=PERSISTENT" parameter. This is where the
redundancy comes in. Someone familiar with annotations but not
familiar with JDO would naturally expect to need only to annotate the
field as @Persistent for it to become, well... persistent. It is
troubling that it is even possible to specify @Persistent on a field
and have it still end up transient.
This annotation was originally named @Field, and when this was the
case, it was perhaps more justifiable to have to pass the
persistenceModifier=PERSISTENT... But when the very name of the
annotation is "Persistent", it is unintuitive that the field may
still remain transient based on a matrix of types that persistent by
default.
>
> Yes, in the case above if MyObject is by default persistent, you
> should not need @Persistent, and it will default to @Persistent
> (persistenceModifier = PERSISTENT, defaultFetchGroup = "false").
> These are the same rules as xml. If you want the field in the DFG,
> you need only type @Persistent(defaultFetchGroup = "true").
Again, MyObject is not by default persistent, so I'm stuck with the
annotation verbosity. In an application making use of a rich domain
model, there will be many dozens of these kinds of declarations,
because most types in the system will be custom types.
> But if the field were by default in the DFG, e.g.
> private Integer someValue;
> the default is @Persistent(persistenceModifier = PERSISTENT,
> defaultFetchGroup = "true") Don't be misled by the default in the
> annotation definition. The annotation default is to overcome a
> deficiency in annotation processing. The real defaults are more
> intelligent.
>
> Bottom line, the semantics of annotations should be identical to
> xml. If not, please let us know.
>
> The issue here is that @Detachable classes are serialization-
> incompatible with non-@Detachable classes. So I think the right
> answer is to require you to specify it :-\
Understood. So, perhaps my latter suggestion of a global option that
specifies the default would be reasonable? e.g.:
javax.jdo.option.DetachableByDefault=true, or something to that
effect. The default for this option would be 'false' for backward-
compat, of course.
>
> Au contraire. "Naive" users are often the best judges of the ease-
> of-use of a specification.
>
>
> I think this is one of the most powerful parts of annotations.
> Defaults are very important to get right.
>
> Craig
>
> 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!
>
|