| Re: [jpa-dev] [nosql-dev] Ideas about relaunch Jakarta EE at a new level. |
Dear All,if I understand correctly there is an interest about this argument, but in this moment it's better that the two technologies (SQL & NoSQL) involve in parallel - for several reasons, one of them is to get good and stable version of Jakarta 10.If you are agree I could begin to deepen and analyse the subject to have clear ideas when the time comes to realize (in one way or another) this multipurposal technology.Do you agree with me? Does it seem logical to you?What I need is the key persons to contact rarely and some link to take useful information (thank you Otavio and Werner for some ideas). Could you give me that, please?I'll try to be as autonomous as possible so as not to steal your time and I'll update you occasionally on progress.Thank you.Dmitri.On Sunday, April 18, 2021, 05:03:37 PM GMT+2, Werner Keil <werner.keil@xxxxxxx> wrote:Otavio/all,
Thanks for Picking up this discussion and trying to get some momentum in it.
We (Otavio, myself or all 3 in some cases when we compared popular NoSQL Frameworks) spoke About this a few times and a „core“ or common „Persistence“ layer that is reusable across relational SQL, NoSQL or Maybe even other (simply file-based) persistence mechanisms would be great. Not sure if we get there in Jakarta EE 10 already and for NoSQL (especially because of its Config roadblock) I have a Feeling that won’t make it into EE 10 because it is not Final and the time seems a bit tight even with a Q1 or Q2/22 proposed release date of Jakarta EE 10.
Think of it as a „Serializable on Steroids“ or „Serializable 2.0“ if you want (did we ever see any outcome of JavaBeans 2.0 in the JDK btw, but they have other priorities there it seems ;-) along the lines of CDI Light a Persistence Light or Core could be used by popular Microframeworks as well and possibly fit into a Core Profile at some Point.
Btw, Forget About Hibernate OGM, that is really dead and Red Hat beside Quarkus also puts all ist resources behind Panache.
That exists for JPA: https://quarkus.io/guides/hibernate-orm-panache
Or MongoDB: https://quarkus.io/guides/mongodb-panache
Don’t ask me if PanacheMongoEntity is based on PanacheMongoEntity and if they plan to share anything other than the Name (and Red Hat is very good at inventing and dropping names almost like tissues ;-) but if people there are worth talking to and getting involved, it’s more the Panache crew than those behind Hibernate OGM even if sometimes you might find the same People involved anyway.
Regards,
Werner
Gesendet von Mail für Windows 10
Von: Dmitri Cerkas via nosql-dev
Gesendet: Sonntag, 18. April 2021 16:58
An: nosql developer discussions; Otavio Santana
Cc: Dmitri Cerkas; jpa developer discussions
Betreff: Re: [nosql-dev] Ideas about relaunch Jakarta EE at a new level.
Hi Otavio, I'm fine, thank you! :)
This is the world where enterprise's developers have (and it's rightly must be so) the data saved, for several reasons, in varios types of databases. And it's an own (Jakarta EE) responsibility, at last, to give them the freedom of switching, as easy as possible, from one database (or database type) to another, manipulate data and write the combined data in yet another db.
If you think about it for a moment, varios SQL (RDBMS) databases are very-very different at the base, but what join them is the small surface interface - the set of rules that let them be classifies as RDBMS (nearly RDBMS :)) ). This surface interface from now should be Jakarta DBCS.
We have already enough knowlenge to combine them in an multipurpose product that will be at the right place in the present world that JDBC held in the past-only-SQL world.
About presence and absence of transactions in MongoDB and Cassandra, if you look at page 9 of "The Third Manifesto" of C. J. Date and Hugh Darwen, you can read:
"Each transaction shall interact with exactly one database. However, distinct transactions shall be allowed to interact with distinct databases, and distinct databases shall not necessarily be disjoint."
i.e., in the case of Cassandra, a transaction may be the same (parallel) think of connection.
Thinking more deeply about Date's phrase above - with our future "Jakarta DBCS" we finally have the possibility to implement one of the fundamental rules of the fathers of database concept (Codd, Date): "distinct databases shall not necessarily be disjoint". :)
If our surface interface of Jakarta DBCS will allow to communicate with 90% of existing databases, the last 10% databases will adjust their surface interface, in one way or another, to enable users to use them via our multipurpose product.
About meetup by hangout or zoom - it's a great idea. I live in Italy - we should agree about the time of meetup.
Thank you. :)
On Sunday, April 18, 2021, 12:02:41 PM GMT+2, Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
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:
We've analyzed also another solution on It such as:
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