I’m good on this personally and would rather invest time on the more long standing issues outlined in the Ambassadors’ Jakarta EE 10 Contribution Guide: https://jakartaee-ambassadors.io/guide-to-contributing-to-jakarta-ee-10/.
It has been clear enough to me for some time why we shouldn’t be trying to make one API for all data sources. To me, even the common annotations may be too much. Ultimately there will probably be many things that are just too different and not generally applicable. I think having a common set of annotations can be explored once Jakarta NoSQL has a bit more market maturity.
For now the focus I think needs to be on making each API successful in its own domain. I am especially concerned about long standing gaps in Jakarta Persistence such as a repository API, alignment with Java SE Records, making the persistence.xml optional, alignment with a Configuration API, etc. 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. On Apr 18, 2021, at 6:04 AM, 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 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. 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 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.
"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.
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.
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 ?
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?
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
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 --------
Date: 1/14/21 6:12 AM (GMT-05:00)
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.
Hello,
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))
_______________________________________________
_______________________________________________
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
--
--
|