Re: [eclipselink-users] [OT]-ish Reading Annotation Data

[RogerV <roger.varley@xxxxxxxxxxxxxx>]

mobrien wrote:
> 
> We welcome any suggestions on extending the JPA 2.0 API implementation.
> I will add extended annotation access to the design page at
> http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api
> 

Hi Michael

I'm coming from being a long term developer on IBM S/38's, AS/400's and
latterly on SAP R/3 systems. These systems all had a "meta layer" that sat
between the application and the database - a definition repository or a data
dictionary if you like. This allowed you to define your data elements once
and once only. So you could define your customer number for example as a 9
digit integer field. You could then define other fields in terms of them
being a "Customer Number" type. Not only could you define the type & size,
you could set default values, display/print formatting rules, text that
would be used as labels when displaying/printing, text that would be used as
help text (tooltips would, I guess, be the java equivalent). The
"disadvantage" I see with JPA & Java, at the moment is that this information
(for example element length) is often defined in multiple locations - it's
in the DB table definitions, it's in the entity annotation, it's in the
validation code/framework and it's often in the html/css definitions as
well.

So I'm wondering if the idea of a "data dictionary" would be of more use.
I've no idea whether this concept would be a welcome addition to
EclipseLink, or even if it's physically possible.  All I can say having used
such systems, that it brings consistancy to displays and reports, eliminates
definition duplication, makes data changes simple to implement application
wide and generally makes life easier.



Regards
 


-- 
View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25660646.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.