Good thoughts.... I think it is a long path forward, and looking at JPA "fragility" and I now doubt it is doable. With fragility, I mean how sensitive JPA applications are to the execution model of JPA itself. Since we don't follow that, I doubt we can make it work reliably.
In regards to SQL Schema to Zest generation; that is actually a really persuasive argument. Are there any existing tools that let you work with an SQL Schema and tell the tool what object model you want out of it? I agree that there is always a schema, and I don't think that anyone really disagrees with that. It is more a matter of "rigid" or "flexible" schema. The "rigid" world requires more process overhead to create and evolve, and over time end up with 500 columns that are mostly empty. So, I am somewhat keen to explore the JDBC track further. Niclas On Sep 18, 2016 20:04, "Jiri Jetmar" <[email protected]> wrote: > Hi guys, > > some lines on this JPA / Zest from me. > > 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 <[email protected]>: > > > 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" <[email protected]> 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 > > > > > > > > >
