openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <>
Subject Re: Metamodel generates ListAttribute for arrays instead of SingularAttribute
Date Wed, 29 Jun 2011 23:34:51 GMT

On Jun 29, 2011, at 4:24 PM, Michael Dick wrote:

> Let me try to reel this one back in, I think some signal has gotten  
> lost.

I agree.
> 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.

There are several array classes that we might consider separately.  
 From a modeling perspective, a byte[ ] is similar to a String, so I'd  
expect it to be treated as a SingularAttribute.

Similarly, char[ ] is the next best thing to a String, and I'd expect  
it to be treated as a SingularAttribute.

But when you go beyond byte[ ] and char[ ], you get into types that I  
would consider second class container types.

short[ ], int[ ], long[ ], double[ ], float[ ], Integer[ ], Short[ ],  
Long[ ], BigDecimal[ ], BigInteger[ ], Employee[ ], etc. are most  
similar to UnmodifiableList reference types that I'd model as  

> 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 <>  
> 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

Craig L Russell
Architect, Oracle
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message