Re: JPA?

2016-09-18 Thread Jiri Jetmar 
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 :

> 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"  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

[jira] [Closed] (ZEST-178) Rework EhCache Cache for EhCache 3

2016-09-18 Thread Paul Merlin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ZEST-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Merlin closed ZEST-178.

Resolution: Fixed

> Rework EhCache Cache for EhCache 3
> --
>
> Key: ZEST-178
> URL: https://issues.apache.org/jira/browse/ZEST-178
> Project: Zest
>  Issue Type: Task
>Reporter: Paul Merlin
>Assignee: Paul Merlin
> Fix For: 3.0
>
>
> EhCache 3 major version breaks API compatibility.
> We should rework the EhCache Cache to use it before putting 3.0 out.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: Zest(JavaEdition)-develop-java9-check #7

2016-09-18 Thread Apache Jenkins Server 
See 


Changes:

[paulmerlin] ZEST-176 Add authentication support to Riak EntityStore

--
[...truncated 5409 lines...]
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.thirtyminutes:test
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:makeVersionClass
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileVersionJava
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileJava
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenDependencies
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenLicense
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenNotice
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:processResources
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:classes
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileTestJava
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:processTestResources
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:testClasses
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:test
 UP-TO-DATE
:coverageReport SKIPPED
:honkerCheck
:rat SKIPPED
:compileJava UP-TO-DATE
:honkerGenDependencies
:honkerGenLicense
:honkerGenNotice
:processResources UP-TO-DATE
:classes
:globalTestReport
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check
:org.apache.zest.core:honkerCheck
:org.apache.zest.core:check
:org.apache.zest.extensions:honkerCheck
:org.apache.zest.extensions:check
:org.apache.zest.libraries:honkerCheck
:org.apache.zest.libraries:check
:org.apache.zest.manual:honkerCheck
:org.apache.zest.manual:check
:org.apache.zest.samples:honkerCheck
:org.apache.zest.samples:check
:org.apache.zest.tests:honkerCheck
:org.apache.zest.tests:check
:org.apache.zest.tools:honkerCheck
:org.apache.zest.tools:check
:org.apache.zest.tutorials:honkerCheck
:org.apache.zest.tutorials:check
:org.apache.zest.core:org.apache.zest.core.api:honkerCheck
:org.apache.zest.core:org.apache.zest.core.api:check
:org.apache.zest.core:org.apache.zest.core.bootstrap:honkerCheck
:org.apache.zest.core:org.apache.zest.core.bootstrap:check
:org.apache.zest.core:org.apache.zest.core.functional:honkerCheck
:org.apache.zest.core:org.apache.zest.core.functional:check
:org.apache.zest.core:org.apache.zest.core.io:honkerCheck
:org.apache.zest.core:org.apache.zest.core.io:check
:org.apache.zest.core:org.apache.zest.core.runtime:honkerCheck
:org.apache.zest.core:org.apache.zest.core.runtime:check
:org.apache.zest.core:org.apache.zest.core.spi:honkerCheck
:org.apache.zest.core:org.apache.zest.core.spi:check
:org.apache.zest.core:org.apache.zest.core.testsupport:honkerCheck
:org.apache.zest.core:org.apache.zest.core.testsupport:check
:org.apache.zest.extensions:org.apache.zest.extension.cache-ehcache:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.cache-ehcache:check
:org.apache.zest.extensions:org.apache.zest.extension.cache-memcache:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.cache-memcache:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-file:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-file:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-geode:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-geode:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-hazelcast:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-hazelcast:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jclouds:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jclouds:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jdbm:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jdbm:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-leveldb:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-leveldb:check

[jira] [Created] (ZEST-178) Rework EhCache Cache for EhCache 3

2016-09-18 Thread Paul Merlin (JIRA) 
Paul Merlin created ZEST-178:


 Summary: Rework EhCache Cache for EhCache 3
 Key: ZEST-178
 URL: https://issues.apache.org/jira/browse/ZEST-178
 Project: Zest
  Issue Type: Task
Reporter: Paul Merlin
Assignee: Paul Merlin
 Fix For: 3.0


EhCache 3 major version breaks API compatibility.
We should rework the EhCache Cache to use it before putting 3.0 out.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: Zest(JavaEdition)-develop-java9-check #8

2016-09-18 Thread Apache Jenkins Server 
See 


Changes:

[paulmerlin] Better error message when unable to set property value in

[paulmerlin] Trivial upgrade of mysql driver to 6.0.4

[paulmerlin] ZEST-178 Rework EhCache Cache for EhCache 3

--
[...truncated 5394 lines...]
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.thirtyminutes:testClasses
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.thirtyminutes:test
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:makeVersionClass
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileVersionJava
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileJava
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenDependencies
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenLicense
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:honkerGenNotice
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:processResources
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:classes
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:compileTestJava
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:processTestResources
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:testClasses
 UP-TO-DATE
:org.apache.zest.tutorials:org.apache.zest.tutorial.introduction:org.apache.zest.tutorial.introduction.twominutes:test
 UP-TO-DATE
:coverageReport SKIPPED
:honkerCheck
:rat SKIPPED
:compileJava UP-TO-DATE
:honkerGenDependencies
:honkerGenLicense
:honkerGenNotice
:processResources UP-TO-DATE
:classes
:globalTestReport
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check
:org.apache.zest.core:honkerCheck
:org.apache.zest.core:check
:org.apache.zest.extensions:honkerCheck
:org.apache.zest.extensions:check
:org.apache.zest.libraries:honkerCheck
:org.apache.zest.libraries:check
:org.apache.zest.manual:honkerCheck
:org.apache.zest.manual:check
:org.apache.zest.samples:honkerCheck
:org.apache.zest.samples:check
:org.apache.zest.tests:honkerCheck
:org.apache.zest.tests:check
:org.apache.zest.tools:honkerCheck
:org.apache.zest.tools:check
:org.apache.zest.tutorials:honkerCheck
:org.apache.zest.tutorials:check
:org.apache.zest.core:org.apache.zest.core.api:honkerCheck
:org.apache.zest.core:org.apache.zest.core.api:check
:org.apache.zest.core:org.apache.zest.core.bootstrap:honkerCheck
:org.apache.zest.core:org.apache.zest.core.bootstrap:check
:org.apache.zest.core:org.apache.zest.core.functional:honkerCheck
:org.apache.zest.core:org.apache.zest.core.functional:check
:org.apache.zest.core:org.apache.zest.core.io:honkerCheck
:org.apache.zest.core:org.apache.zest.core.io:check
:org.apache.zest.core:org.apache.zest.core.runtime:honkerCheck
:org.apache.zest.core:org.apache.zest.core.runtime:check
:org.apache.zest.core:org.apache.zest.core.spi:honkerCheck
:org.apache.zest.core:org.apache.zest.core.spi:check
:org.apache.zest.core:org.apache.zest.core.testsupport:honkerCheck
:org.apache.zest.core:org.apache.zest.core.testsupport:check
:org.apache.zest.extensions:org.apache.zest.extension.cache-ehcache:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.cache-ehcache:check
:org.apache.zest.extensions:org.apache.zest.extension.cache-memcache:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.cache-memcache:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-file:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-file:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-geode:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-geode:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-hazelcast:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-hazelcast:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jclouds:honkerCheck
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jclouds:check
:org.apache.zest.extensions:org.apache.zest.extension.entitystore-jdbm:honkerCheck

[jira] [Closed] (ZEST-176) Rework Riak EntityStore for Riak 2

2016-09-18 Thread Paul Merlin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ZEST-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Merlin closed ZEST-176.

Resolution: Fixed

> Rework Riak EntityStore for Riak 2
> --
>
> Key: ZEST-176
> URL: https://issues.apache.org/jira/browse/ZEST-176
> Project: Zest
>  Issue Type: Task
>Reporter: Paul Merlin
>Assignee: Paul Merlin
> Fix For: 3.0
>
>
> Riak 2 Java Client only supports protocol buffer based communication, no more 
> HTTP. We will go from two EntityStores implementation (protobuf & http) to a 
> single one.
> Riak 2 introduced support for authentication. This should be added to the 
> Zest ES.
> See 
> https://github.com/basho/riak-java-client/wiki/Riak-Java-Client-2.0-Upgrade-Guide



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: JPA?

2016-09-18 Thread Niclas Hedhman 
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"  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 :
>
> > I am doing