| Re: [jpa-dev] [nosql-dev] Ideas about relaunch Jakarta EE at a new level. |
Hi all,
thanks Reza for kicking this off, thanks Otavio for finding those statements. It would've caused me quite a bit of time to look them up.
I can relate to the urge of coming up with the canonical abstraction of data stores. There's always a "This can be just be abstracted with that…" around the corner. In the end, everything is just an Object, right? Even worse, you actually *can* build these abstractions. The question is just how useful they are. Let me quickly guide you through the state of JPA as a persistence technology as I have seen it discussed in the recent years and try to derive some general challenges that *any* kind of persistence technology faces with developers trying to use it theses days.
Contrary to popular belief, the primary starting point to think about this is the user's code, *not* technology. Whether you can make X just Y to pipe it through some JDBC-like API doesn't matter. In fact, it can be highly misleading, because it incentivizes solving the wrong problem. That said, let's have a look at what abstraction levels user code, that needs to be persisted, can live. It usually lives on a spectrum that's bounded by the following "extremes":
1. Domain-oriented -- the code is using domain (meta) abstractions to fit into architectural concepts. It uses a pattern language, a meta model, and tries to express that. A very commonly used one: DDD building blocks. Aggregates, entities, value objects. The idea is to be able to easily identify and implement business and consistency rules by assigning building block roles to code to be persisted. That code is usually supposed to be "free of (constraining) technology". The mapping onto the data store can largely be derived from the meta model element structure: references to other aggregates should be to-id instead of to-object, persistence operations should not cascade over aggregate boundaries etc.
2. Data-oriented -- the code is a very close reflection of the underlying data store. The abstraction level is not very high. Developers usually explicitly opt into that model, because they prefer a very direct mapping between the persistence model and their code. They want control, which means they're also fine to deal with technical details right with in the model or the code that's handling persistence.
In fact, most schools of the former recommend to use the latter in a dedicated part of the codebase, i.e. the domain model is accompanied with a dedicated persistence model and there's a dedicated mapping step between the two. How does JPA fit into that picture? Not too well, unfortunately, and I don't mean that in a derogatory way. Here's a tiny example that shows what I am trying to get to:
class Order {
Customer customer;
List<LineItem> items;
}
In JPA, Order, Customer and LineItem are @Entities. However, the concept of an entity in JPA is not equivalent to the one in DDD. That in itself is not a big problem, the constraints attached to the technical concepts and especially the lack of other high-level concepts like Aggregates in the mapping has consequences: depending on the actual high-level arrangement, we need to enrich the model with technology specific annotations. We can't properly express that Order and Customer are an aggregate, and that line item is not. We cannot explicitly express that customer is an association to another aggregate. Instead we *implicitly* express that by implementing repositories for Order and Customer (which is kind of the core of Spring Data) and map the items using cascade operations as Order controls the lifecycle of the LineItems. In fact, LineItems are not even entities conceptually, they could be value objects, but JPA *requires* to annotate them with @Entity, because they need to have an id in the datastore.
** Fundamentally, the lack of means to express domain level concepts requires us to pollute domain code with technology specific annotations. **
In other words, JPA creates incentives to create a model that's living right between the two opposite ends I described above. You need to add boilerplate annotations perceived as technical noise to your domain model to express high level concepts. In the last couple of years, I've seen developers move off JPA for that fundamental reason (also leaking through in other parts of the API, like lazy loading etc.). Most folks decide for more "precise" APIs: we've seen jOOQ gain significant traction, Spring Data JDBC has been pretty successful with a object mapping model that takes the former model approach, derives a lot of the necessary mappings but at the same time then provides means of the latter to be very precise about customizations.
Also, the jMolecules [0] project provides means to very explicitly model patterns described in the domain-oriented model section and then -- via jMolecules Integrations [1] -- adds the necessary default mappings derived from the high level concepts. It effectively translates the domain oriented model into a data oriented one *without adding noise to the code*. This [2] is a fully working, JPA-persisted model without any JPA specific annotation at all, only using high-level domain abstractions.
What's the relationship to the original topic you might ask? What I think you can see from all this is that a persistence mapping technology comes with significant baggage if it's trying to abstract technology too much and at the same time is not elevating the abstraction level into the domain. An "Everything is a persisted object and we can map it to a store no matter what type" is an abstraction without significant benefit to application developers. OGM was discontinued because trying to map an API that's based on relational concepts doesn't fit well on NoSQL stores. It's been -- IMO -- backwards: we have a solution, let's try to make the problem fit. I've never seen that fly. Never.
That said, please don't read this as criticism on either OGM or JPA. We've come to learn with its traits and it does a decent job of persisting simple objects. It's just also proof that that isn't necessarily where the real challenges for developers are, which I why I don't think it's a good idea to make this over-simplified problem description the primary goal of any mapping specification effort.
Hope that helps!
Ollie
[0] https://github.com/xmolecules/jmolecules
[1] https://github.com/xmolecules/jmolecules-integrations
[2] https://github.com/xmolecules/jmolecules-integrations/tree/main/jmolecules-examples/jmolecules-spring-data-jpa/src/main/java/org/jmolecules/examples/jpa
> Am 18.04.2021 um 12:02 schrieb Otavio Santana <otaviopolianasantana@xxxxxxxxx>:
>
> Hey, how are you?
> Thank you for including me in this discussion.
> Indeed, in Java history, we have this kind of API: the Java Data Object, the JDO: https://www.oracle.com/java/technologies/java-data-objects.html
>
> We've been discussing it several times in the email list, such as this one:
> https://github.com/eclipse/jnosql/issues/165
>
> In summary, we can use Oliver comments:
> • https://github.com/eclipse/jnosql/issues/165#issuecomment-483211611
> • There is this talk also in the stack overflow
>
> We've analyzed also another solution on It such as:
> • Eclipse Link NoSQL
> • Hibernate OGM
> Both did not go further because NoSQL has a huge difference. Besides, there are a couple of details in the NoSQL world, such as MongoDB has transactions; however, we need to think twice because of the performance issue. Also, there is Cassandra, who does not provide transactions at all, and so on.
>
> Summary, when we a boat API and move it on the plane just because both are transport tends to be a bad idea.
>
> I'm glad to help on it, and yes, once both are persistence API, we can think about how we can work together, such as a standard way to follow the Third Factor App and so on.
>
> Please, let me know if you wanna do a meetup by hangout or zoom.
>
>
>
> On Sat, Apr 17, 2021 at 6:46 AM Dmitri Cerkas via nosql-dev <nosql-dev@xxxxxxxxxxx> wrote:
> "If I am understanding things correctly, what you are trying to suggest is a generic API for all data access technologies?"
> Yes, this is my idea.
>
> 1) if any database (SQL or NoSQL) is a storage for: connect to it, write (insert), read (select) and modify (update) of data,
> 2) taking in account that now JDBC allows users to work with different RDBMS (SQL) databases by: connecting to them, writing, reading and modifying data,
> 3) and taking in account that now users accessing data via JDBC write custom queries sutable for a specifical database (queries for DB2 are not identical to the queries for Oracle DB)
>
> why not allow users to:
> 1) write connection string for connecting to NoSQL database as well,
> 2) write custom queries for select-insert-update-delete data in that particular DB ?
>
> Data can be always represented by java objects (both in the case of SQL DB, "linear NoSQL DB" or "XML NoSQL DB") (in the case of XML NoSQL databases the structure of data (I mean Java-side) can be similar to X-stream approach).
>
> There are always be "PreparedStatement", "ResultSet" and "executeQuery", but on an extended level - users will have the possibility to query "NoSQL DB".
>
> Maybe I don't perceive the underlying problems because of my ignorance, but if that problems can be overcome we will have a universal (multipurpose) Jakarta DBC for ALL database types similar to that as was JDBC for ALL RDBMS (SQL) database types.
>
> Thank you,
> Dmitri.
>
>
> On Saturday, April 17, 2021, 04:52:47 AM GMT+2, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
>
>
> I am including the Jakarta Persistence and NoSQL mailing lists as these are the right places to start this discussion.
>
> If I am understanding things correctly, what you are trying to suggest is a generic API for all data access technologies?
>
> This is an idea that I believe in particular has been well discussed at least by Otavio Santana. The practical problem is that it is very difficult to arrive at one API that suits all data storage technologies adequately. Indeed it is very difficult even to arrive at one API for all NoSQL taxonomies.
>
> That said, I know folks involved have expressed interest in having at least a common set of annotations - which is more achievable. Perhaps the folks in the respective aliases can share the current thoughts on the topic?
>
> Hope it helps?
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> P.S.: JDBC is a Java SE technology defined by the JCP, not a Jakarta EE technology. I don't think there are any plans to move JDBC to the Eclipse Foundation or evolve it to cover NoSQL.
>
> On 4/16/21 1:23 PM, Dmitri Cerkas wrote:
> Hi Reza,
>
> may be you remember me - I'm Dmitri - you are keeped me in touch with "Jakarta EE Tutorial" group and I am very grateful to you for that - thank you! My last activity in the Jakarta EE Tutorial team was the full recreation of all images from PNG to SVG format and I pushed all 68 images in a new format yesterday! :)
> Soon I'll review whole tutorial, because, in my opinion, some paragraphs are structured no so well and are not quickly understandable.
> Thank you again for opportunity!
>
> About my idea of how to relaunch Jakarta EE to make it the standard even wider thean now in the field of Information Technology - I think it's necessary to review all Jakarta's components to make them global (multipurpose).
>
> For example, JDBC that now is valid only for SQL-databases can be trasformed in something like "Jakarta DBMS" standard (or DBIS (database interacting standard)) capable of interacting with ALL types of databases (RDBMS, SQL, No-SQL, ecc). This can involve upgrade of some components of Jakarta EE, for example, EJB, JPA, JTA to become universal (multipurposal).
>
> I'm Java Developer Master with 6 Oracle's certificates in Java, Database Administrator Certificated, Linux System Administrator Certificated and now I'm preparing for Software Architect certification.
>
> If you like my idea I can start analyse the possibility of how JDBC and various related components can be upgraded for working with ALL types of databases.
>
> After that we can analyse other Jakarta EE components of how expand their use globally.
>
> Thank you,
> Dmitri.
>
>
>
> On Wednesday, April 7, 2021, 06:45:06 PM GMT+2, Zahid Rahman <zahidr1000@xxxxxxxxx> wrote:
>
>
> I understand the popularity of Java spring.io versus Java EE is 80:20 in favour of spring.
>
> What does the community think is the cause of this disparity and what can be done to close the gap ?
>
>
>
> Z.
>
> Jakarta EE Application Developer skill challenge
>
> https://lit-taiga-52898.herokuapp.com/
>
>
> https://www.backbutton.co.uk/
> ¯\_(ツ)_/¯
> ♡۶♡۶ ♡۶
>
> On Wed, 7 Apr 2021, 17:18 Tanja Obradovic, <tanja.obradovic@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hello dear Jakarta EE Community ,
>
> As you may know know, we are making the 2021 Jakarta EE Developer survey available as of today.
>
> To maximize our outreach, we are reaching out to our community channels to promote the survey. Can you please share this link and help us engage with the community?
>
> -Jakarta EE Community : https://www.surveymonkey.com/r/FD2GWM8
> To make it easier to promote we have created Social kit to use and promote on the socials.
>
> Many thanks!
>
> Tanja
> --
> Tanja Obradovic
> Jakarta EE Program Manager | Eclipse Foundation, Inc.
> Twitter: @TanjaEclipse
> Eclipse Foundation: The Platform for Open Innovation and Collaboration
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
>
> On Thursday, January 14, 2021, 03:40:39 PM GMT+1, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
>
> It is a fine question. I have not had a chance to respond properly yet. I will as soon as I can.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Dmitri Cerkas <dmitricerkas@xxxxxxxxx>
> Date: 1/14/21 6:12 AM (GMT-05:00)
> To: Reza Rahman <reza_rahman@xxxxxxxxx>
> Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] About "Jakarta EE 9 Tutorial".
>
> Reza, sorry... did I asked yesterday something wrong?
> I'm a new entry in Jakarta EE community and may be some questions cannot be asked?
>
> Dmitri.
>
>
> On Wednesday, January 13, 2021, 12:44:39 PM GMT+1, Dmitri Cerkas <dmitricerkas@xxxxxxxxx> wrote:
>
>
> Hello,
>
> sorry, one question... Will be created "Jakarta EE 9 Tutorial" similar to that of "Java Platform, Enterprise Edition (Java EE) 8 The Java EE Tutorial" (https://javaee.github.io/tutorial/toc.html) ?
>
> Thank you in advance!
>
> Have a nice day,
> Dmitri Cherkas.
>
> - Oracle Certified Master, Java SE6 Developer
> - Oracle Certified Professional, Java Enterprise Edition 5 Web Component Developer
> - Oracle Certified Professional, Java ME1 Mobile Application Developer
> - Sun Certified Java Programmer (SCJP) v. 1.5
> - Sun Certified Java Programmer (SCJP) v. 1.6
>
> - Oracle Certified Associate Database 11g Administrator
> - Oracle Database 11g: SQL Fundamentals I
>
> - Linux System Administrator Certified, LPIC-1 (Linux Professional Institute)
>
> - Degree in Computer Science,
> - Degree in Economics
>
> - CEH (Certified Ethical Hacker (CEH) (EC-Council)) (in progress)
> - Software architect (iSAQB certification (in progress))
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> _______________________________________________
> nosql-dev mailing list
> nosql-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
>
>
> --
> Otávio Santana
>
>
> twitter: http://twitter.com/otaviojava
> site: http://about.me/otaviojava
>
> _______________________________________________
> nosql-dev mailing list
> nosql-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jpa-dev