openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: Metamodel generates ListAttribute for arrays instead of SingularAttribute
Date Wed, 29 Jun 2011 23:24:09 GMT
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

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.


On Wed, Jun 29, 2011 at 1:41 PM, Pinaki Poddar <> 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:
> Sent from the OpenJPA Developers mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message