Hi Chris, It is perfectly reasonable to have the annotation
@Persistent private MyObject obj;
and have field obj actually be persistent.
The xml metadata is a bit unhelpful If you annotate <class name="foo"> <field name="obj"/> ... </class> I think that foo is transient because of defaults.Let's see how to make this more helpful, both for xml and annotations. I don't want to make it more difficult for xml just because we fix annotations.
Craig On Aug 8, 2007, at 6:12 PM, cbeams wrote:
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:Having used the annotations in their evolving forms for the last several months, I and my fellow developers have gotten very used to typing:@Persistent(persistenceModifier = PERSISTENT, defaultFetchGroup = "true")private MyObject obj;To the uninitiated, it seems rather redundant to be using an annotation named "@Persistent", and then have to pass in "PERSISTENT" again. It would be nice if this were the default, and in the (in my experience) much less frequent cases of TRANSIENT/UNKNOWN/NONE, I'm free to configure away.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.The same goes for defaultFetchGroup. Granted, I'm building an application that relies heavily on detachment, thus I want everything in my DFG, but from an ease-of-use / reducing the learning-curve point of view, I'd like to consider introducing 'reasonable defaults' into the annotations, such that I can type@Persistent private MyObject obj;and it will 'just work', whether I'm attached / detached, etc. As I begin to optimize, and want to take things out of my DFG, I can configure that easily enough by passing defaultFetchGroup = "false", but at that point, I must care about it enough to figure it out, right? (refer to hype in general about convention over configuration :-)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.While I'm on the topic, would it be unreasonable to make the 'detachable' parameter to @PersistenceCapable default to "true"? If this has performance implications (i.e.: extra bytecode has to get added during enhancement for objects that are detachable vs those that aren't), perhaps an option could be introduced to advise the implementation whether detachable is "true" or "false" by default. I know for me, every single one of my calls to @PersistenceCapable includes a 'detachable="true"'. This just feels punitive after a while.The issue here is that @Detachable classes are serialization- incompatible with [EMAIL PROTECTED] 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.I haven't given a great deal of thought to these suggested changes and their possible ramifications, but perhaps that's the benefit of being an 'ignorant user'...Au contraire. "Naive" users are often the best judges of the ease- of-use of a specification.I just know what I want from a convenience and ease-of-use point of view. That said, one implication I can think of is that the annotations' default behavior would no longer map directly to that of the already-established XML metadata. The second paragraph of the preamble to chapter 19 would have to change to accommodate this. It currently reads:The annotations described herein support the entire range of metadata that can be expressed using the xml format. Annotations have identical semantics to the corresponding xml metadata.The semantics might be the same, but the defaults would be changing. We would want to account for this in the spec, I'm sure.I think this is one of the most powerful parts of annotations. Defaults are very important to get right.CraigFood for thought, thanks much. - Chris Chris BeamsCraig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
