Let me try to reel this one back in, I think some signal has gotten lost. The example I'm concerned with is a byte array. The problem I'm trying to solve is that of compatibility with canonical metamodel classes.
For example, I would expect the canonical metamodel classes generated by Dali to work with OpenJPA. As I understand it, they do not work because Dali generates a SingularAttribute for byte arrays. My read of the spec is that using a SingularAttribute is correct. Collection valued fields are generally used to refer to relationships. This can be extended to encompass @PersistentCollections, but shouldn't apply to a byte array. While I understand your opinion that the spec came second, I think that the point of the spec is to address compatibility issues like this one. -mike On Wed, Jun 29, 2011 at 1:41 PM, Pinaki Poddar <[email protected]> wrote: > Arrays are specialized Lists. Or Lists are specialized Arrays. Like > Rectangle > is a specialized Square. Or Square is a specialized Rectangle. Formal > language inheritance concept does not pin this either way but allows one to > consider either view. > > OpenJPA had so far modeled Array as second-class container in a consistent > manner as it did for java.util.Collection and its subtypes. I support such > modeling. It also has an extra makeDirty() because of technical complexity > of tracking changes in second-class containers w.r.t Arrays. > > From that viewpoint of maintaining continuity of design principles of the > original authors, the modeling of Array as List is correct, imo. > > Primitive collection requires different treatment. That is why JPA 2.0 had > to annotate @ElementCollection to distinguish from reference collection. > Let > us keep that aside for the time being. > > Now on why "X spec says so..." is a weak argument > > Specs are combined voices of you and I and all the people who are brave and > crazy enough to explore new ideas in open source projects. Specs follow > Open > Source. Not the other way around. Open Source is the playground where > technical debate (as we are now engaged in) takes place, where new ideas > emerge. If the ideas are solid and the democracy of users accept it -- then > the spec of future years will adopt it. > > As far as persistence of Arrays is concerned -- JPA spec says almost > nothing. The onus is on us as open source developers who have to figure out > what is a *good* way. If the users accept it -- then we did a good job and > we can take our view to the experts of spec committee to make that view > part > of a standard. Today where JPA spec stands is a testimonial to such effort > by Hibernate or Kodo and many others who built their software *without* a > spec guiding them what to do or what is the "right" way. In fact, it is > they > who made today's JPA spec possible. That is why I said : "X spec says > so..." > is a weak argument in a open source context. > > > > > > ----- > Pinaki > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/Metamodel-generates-ListAttribute-for-arrays-instead-of-SingularAttribute-tp6529049p6530220.html > Sent from the OpenJPA Developers mailing list archive at Nabble.com. >
