 [JPA-Newbie] -- JPA 2 for dynamic/custom entity types (database schemas)? [message #657000] |
Tue, 01 March 2011 05:33  |
Eclipse User |
|
|
|
Dear EclipseLink forum members:
Still being new to JPA and having worked through the JPA2 spec as well as the corresponding Apress book for learning the underlying concepts, I am currently wondering if my current, rather dynamic application scenario can be realized in JPA2 in an easy way.
The simplified app scenario is like the following:
Suppose there should be a JEE6 web app that allows endusers to publish articles. There is a generic "Article" type with some common/default attributes such as
- author : String
- pubDatetime : String or own.DateTime
- title, subtitle, articleText : String
- ...
Additionally, a privileged group of endusers should be able to enhance this generic "Article" type by custom attributes during runtime (i.e., dynamically) and via a web interface. Additional attributes could be
- articleTopic : ArticleCategoryEnum
- rating : Float
- comments : List<String>
- ...
I guess the intention should be obvious and btw. not uncommon.
My remaining question basically is:
1. Is (EclipseLink) JPA 2 good for realizing such a dynamic scenario? If so, how could this be fulfilled in JPA 2 the best way.
2. In the contrary case, what alternative technologies would be a good practice for solving this dynamic problem?
Due to the topic's importance for me, I'd be very grateful for any help or other productive tips/hints.
Thank you very much in advance.
- Sebastien
|
|
|
|
| Re: [JPA-Newbie] -- JPA 2 for dynamic/custom entity types (database schemas)? [message #657292 is a reply to message #657105] |
Wed, 02 March 2011 05:55  |
| Eclipse User |
|
|
|
Dear James:
first of all, thank you very much for your hint.
Yes, *Maps* were one of the two general (i.e., not JPA specific) possibilities I could imagine before. For JPA, as I guess that it will be "hard" to create dyn. db schemas and maintain their evolution, I think the Map-based solution will be the best for me.
If I got it right, a "basic" Map-based solution storing String-based attribute value representations don't guarantee type maintenance and type safety, does it?
How could a Map-based solution be realized that distinguishes the several atomic and composed attribute types ('composed' in the sense of collection types consisting of (a) collection kind (array, list, set, probably map) and (b) element type (e.g. List<Person>))???
Thank you (all) very much for any further hints or mapping examples.
Best regards
- Sebastien
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03500 seconds
Home