2

I am trying to create web application that allow its users to create new forms and tables (many ERP applications have such feature). It is clear about generating and saving HTML forms and it is clear about generating new tables in database as well. But what about entities, e.g. Spring @Entity and @Repository classes.

One can try to compile then on the fly and save into the web application deployment directory, that should be possible. But is there need to update some kind of internal Spring registry of existing beans, repositories and controllers. Does Java JPA have such registry as well?

Is it possible to do such kind of thing? It is clear that it is possible to do this in php, e.g. to dynamically update yii framework application, because there is no compiled code (except, maybe, cached code) and with each new request the available paths are scanned anew. But how this happens in Enterprise Java and Spring applications?

Maybe I should look for Groovy Grails or Scala Play - they may be more dynamic languages.

TomR
  • 2,696
  • 6
  • 34
  • 87
  • 2
    Here is the solution with new persistence XML loading http://stackoverflow.com/questions/8448950/adding-entity-classes-dynamically-at-runtime – davidluckystar Jun 27 '15 at 13:28

3 Answers3

2

More "object java storages" compatible with JPA (ObjectDB and Co) promise smoother, more natural migration with extra fields and classes. I haven't personal opinion.

EDIT: good perspective has, I think, philosophy ActiveRecord and similar. Few solutions in Java are ready. I have tried such solutions with partial success, but my project was not too dynamic (classes were stable) and we switched to clear JPA.

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
Jacek Cz
  • 1,872
  • 1
  • 15
  • 22
1

  1. some ERP applications (in different languages f.e.C,Java.C#) have an idea "kernel class and additional fields", ie. Customer with all typical fields plus "Preffered color" (usually implemented in extra hidden tables). This is OK if they don't need new relations

  2. Eclipselink has similar concept 'extra fields' in JPA area (not strict standard JPA but extension) https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic At project level, seems to be OK enter non-critical data

3 Ist hard to imagine create high count of dynamic important/central classes (tables) without radically redesigned application (proverbially version 2.0 ;) )

  1. Sometimes I try stop and restart EMFactory with different Persistence Units (in Tomcat environment) with Hibernate and Eslipselink, but not use in production. Reset & start seems be ok, this is like rupture and new life of JPA engine. Its more like application 2.0 than small patch.

  2. Creating multiple gemmini table sets (for different companies in the same database) is good in Hibertate and Eslipselink (prefix before table name), few dedicated lines by start, normal clean JPA use. Tested, all OK.

Jacek Cz
  • 1,872
  • 1
  • 15
  • 22
1

Once again, adding single/few tables is poorly reworked in the community. It is an interesting discussion to "glue" together common JPA modules (code+JPA), this is done often by OSGI programmers. Theoretically so it has to module give your tables, strongly connected in the same PU.

At the ERP application level it can be anything from "add CRM module" to "kernel + sales". I'm an interested spectator, but i have not seen any success.

If you look in the google integrate persistence unit from parts, composite persistence unit, many programers try to reach such target. It is like a fishing rod rather than fish (as the old adage goes).

Persistence Unit conception isn't friendly for such ideas (and is blocked in standard JPA).

George Yeoell
  • 27
  • 10
Jacek Cz
  • 1,872
  • 1
  • 15
  • 22