Hi guys, some lines on this JPA / Zest from me.
Advertising
The requirement to be able to use JPA on Zest has from my perspective three reasons: 1) Standardized, aka "JPA-way" to persist and query Entities (persistent Objects with Identities) 2) Be able to use a (relational-) schema that has been externally modeled and "materialized" in the repository, e.g. kind of ER-Model 3) Accessibility by other applications The reason for 1) is pretty straightforward - there are potentially millions of developers that knows what JPA is and how to use it. When you have a project X and the target platform is for what ever reasons Java and you have to store & query application related states - then you are looking for JPA support. That simple. On a long term, you are adding lot of complexity and issues using the nowadays popular Titanic-Class ORM mappers, but this "secrets" are mostly unknown by the decision-makers. >From my own experience I know how hard it is to convince developers to use the "Zest" way of Domain Modeling and it takes months of hard work before the brain switches over to the Zest way. This is for large projects a serious issue and a huge risk that just few managers will take ! The second reason is a bit more versatile. The last 20-30 years was the "relational era". The relational model was derived from the relational algebra and in the beginning people believed that it is impossible to develop it in software - but then the first relational databases was introduced.. Now some people believe that we are living in the post relational era, where things are "schema-less" and therefore the NoSQL repositories are buzzing.. Then we have the CAP Theorem that indicates the limits of the "classical" repositores.. (but that has nothing to do directly with SQL/NoSQL repositories..) I personally believe that this schema-less argumentation is a just non-sense. There is always a schema. Either there is a single and unique place, a kind of "horizon of truth", like that what can be found in the typical ER-Models or the model is distributed across a number of places, like the application code or even in the developers brain (where is gradually evaporates). There is always a schema. The third point is that one wants sometimes to access (and in some case mutate) the models (and also the states) using 3th party tools. The reason can be e.g. to evolve the Domain Model using some Modelling Tools or even doing things like fixing issues directly in the repository - means changing data. The current approach in Zest where simply the serialized Objects as JSONs are stored in the repository is simply hard to be used by 3th party tools. I played with the JSON build-in type in Postgresql where then it is possible to CRUD using SQL the Zest Entities, but this is everything else then straightforward. If I had some free wishes on Zest, I would argue in this directions : i) Support external schema development, at least for the relational (SQL) repositories ii) Keep the ES / EI segregation as this is the coolest thing since sliced bread; optional support SQL based indexes. iii) Find a nice way to map Zest entities to the external schema; keep it simple, do not build a ORM Titanic iv) JPA is at least for me not required, plain old (and direct) SQL is fine With i) it would be possible to use Zest even on existing applications where the schema already exists and can not be changed. ii) is clear - the external index is just crazy cool. Optionally it would be nice to use a SQL Index, when one does not want to use ElasticSearch for Indexing iii) requires some nice/simply way how to model entities in Zest and map them to the external schema. iv) well, JPA is from my perceptive not a must. Plain old SQL is just fine. e.g. a tool like http://www.jooq.org/ can be used to generated the required SQL statements ? Cheers, Jiri 2016-09-05 3:49 GMT+02:00 Niclas Hedhman <hedh...@gmail.com>: > I am doing the Pet Clinic migration to Zest, partly to show how horrid the > HOA stuff is in comparison. In real world project, the situation is often > much worse as entities and data transfer classes are separate (not the case > in Pet Clinic) > > So, perhaps the answer is simply a migration strategy and a great vision > that reduces "clutter". > > Cheers > Niclas > > On Sep 5, 2016 08:02, "Paul Merlin" <paulmer...@apache.org> wrote: > > > Kent Sølvsten wrote: > > > >> This is a tough, but interesting question ...... > >> > >> [SNIP] > >> > >> A few ideas: > >> > >> (1) > >> If the persistence engines in the entitystores are XA capable (such as > >> for JDBC/NEO4J entitystores) it should not be too difficult. > >> The basic idea would be to inject a DataSource provided by the appserver > >> into the EntityStore and let the EntityStore avoid committing - leaning > >> on commit of the global XA transaction > >> - and postpone notifying indexers until the global transaction is > >> committed (we should be able to listen to "commit events"). > >> > > > > I did just that with the SQL ES a few years ago. > > I provided the SQL ES with a Connection that would delegate to a XA > > Connection and avoid committing, letting the responsibility to commit to > > the application server. > > It's working in production since then. But it's nasty and I've been > lucky, > > especially because of the presence of an Indexer in that application .... > > > > One simple way to look at JPA integration would be to simply use Zest > > without using its persistence related features. > > i.e. "if you use JPA, you don't need (cough!) Zest persistance" > > > > For this we could do various things to ease users pain: > > - show (sample, doc, whatever) how one can use composites for e.g. only > > their service layer while running in some horrid application server and > > persisting with JPA > > - have a Value <-> POJO converter, to move state from one world to the > > other if you really want to > > > > IOW, I'm note sure about the value of some JPA/UoW integration. > > > > My 0.2 cents > > > > >
