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
Collections.
Craig
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.
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
