Jakarta NoSQL 1.1

Transcript

1. Template A common API designed to remain extensible across different NoSQL models Template Core API (Common Operations) insert(...) update(...) find(...) delete(...) select(...) query(...) Supported NoSQL Models  Key-Value  Column  Document  Graph  Time Series  Vector Provider / Model Extensions (Optional Specific Capabilities) Custom Extensions & Native Features Allows underlying database drivers to expose specialized operations, native query languages, or model-specific enhancements without breaking the common API foundation.
2. Familiar Annotation Model Jakarta NoSQL reuses familiar mapping concepts while extending them for NoSQL needs Core Mapping Composition & Reuse @Entity @Embeddable @Id @MappedSuperclass @Column Inheritance Conversion & Projection @Inheritance @Convert @DiscriminatorColumn @Converter @DiscriminatorValue @Projection 💡 Familiar concepts for Jakarta Persistence developers help drastically reduce cognitive load when modeling NoSQL entities.
3. Product Mapping Persistable attributes must be explicitly mapped Product.java @Entity public class Product { @Id private String id; @Column private String name; @Column private String category; @Column private BigDecimal price; // Unannotated field: NOT persisted private String internalComment; } ⚠ Important In Jakarta NoSQL, persistable attributes should be explicitly annotated. Unannotated attributes are ignored.
4. Core Operations Common persistence operations without a query builder Insert Product product = new Product(...); template.insert(product); Update product.setName("Updated Name"); template.update(product); Find Optional<Product> product = template.find(Product.class, id); Delete template.delete(Product.class, id);
5. Fluent Operations Compose richer selections and deletions through a fluent API Fluent Select Fluent Delete List<Product> products = template.delete(Product.class) template.select(Product.class) .where("status").eq(ProductStatus.DISCONTINUED) .where("category").eq(ProductCategory.BOOK) .execute(); .and("price").lt(new BigDecimal("50")) .result(); Method Flow select Method Flow where and result delete where execute
6. Key-Value Fast access when the key is already known KeyValueTemplate.java Best-Fit Scenarios • • • • • Key Sessions Caching Shopping carts User preferences Simple state lookup Value @Inject KeyValueTemplate template; // Store value by key template.put(car); // Retrieve value by key Optional<Car> car = template.get(1L, Car.class); // Delete value by key template.delete(1L); Retrieves the complete value by key, rather than querying individual attributes or inner fields. Conceptual Serialization Car Object Driver Serialization Stored Value Complete object is stored as the value. Format depends on the driver/provider: Driver-dependent examples: • Java/native binary • Text / Plain string • JSON document • Provider-specific format Eclipse JNoSQL implementation API
7. Column Optimize large distributed datasets around known access patterns Core Architecture • Organized around rows and column families • Individual pieces of information can be represented as columns • Designed for large distributed datasets • Data modeling is strongly influenced by the queries the application needs Row Key ├─ name ├─ city ├─ type └─ ... ColumnTemplate.java @Inject ColumnTemplate template; // Insert entity template.insert(car); // Lookup by primary key Optional<Car> car = template.find(Car.class, 1L); Architectural Considerations • Primary-key-oriented access: Built for scale and extreme write throughput. • Secondary indexes: Can enable additional access paths, but availability and performance depend heavily on the underlying database. • UDT / Structured types: Database-specific capability where supported, not a universal Jakarta NoSQL guarantee. // Fluent query delete template.delete(Car.class) .where("id").eq(1L) .execute(); ! Optimizes layout on disk by grouping related columns together for multi-node efficiency. Model for the queries you need Always design tables around access patterns first. Avoid relational join paradigms as cross-partition queries carry heavy performance penalties. Eclipse JNoSQL implementation API
8. Documen tStore and query flexible object-shaped data JSON Document Structure { "id": 1, "name": "Ferrari", "city": "Rome", "type": "SPORT" } • Naturally maps to nested object structures • Flexible schema without pre-defined column constraints • Multiple attributes can participate in complex queries • DocumentTemplate.java @Inject DocumentTemplate template; Querying Documents Documents align seamlessly with application domain models rather than relational tables. // Insert entity template.insert(car); // Lookup by primary key Optional<Car> car = template.find(Car.class, 1L); // Fluent query delete template.delete(Car.class) .where("id").eq(1L) .execute(); // Compact Query Example Optional<Car> result = template.singleResult( "FROM Car WHERE _id = 1" ); ! Good fit for aggregate-oriented domain data Object-Centric Storage Unlike relational rows bound to strict schemas, documents preserve object shapes natively, enabling rich queries across nested fields. Eclipse JNoSQL implementation API
9. Time Series Model measurements where time is part of the identity SensorReading.java Timeline & Use Cases @Entity 10:00 21.5 10:01 21.7 10:02 21.6 public class SensorReading { @Id private Instant timestamp; @Column private String sensor; Well suited for: • Metrics • Telemetry • IoT sensor readings • Monitoring • Financial observations @Column private double value; } TimeSeriesTemplate.java @Inject TimeSeriesTemplate template; // Insert record template.insert(reading); // Lookup by timestamp Optional<SensorReading> result = template.find(SensorReading.class, reading.getTimestamp()); // Query by sensor template.select(SensorReading.class) .where("sensor").eq("sensor-1") .result(); ! Time-oriented identity The identifier should be time-oriented for this model, such as Instant. Eclipse JNoSQL implementation API
10. Vector Map identity, embedding, and payload into a vector record Article.java @Entity public class Article { @Id private String id; @Column private String content; @Column private String author; @Column private int year; @Column private String category; @Column private Vector embedding; } Conceptual Qdrant Record Point ├── id -> "article-123" ├── vector -> [0.12, -0.45, ...] └── payload ├── content -> "Jakarta..." ├── author -> "Otavio Santana" ├── year -> 2026 └── category -> "Java" VectorSearchExample.java // Nearest-neighbor search // with metadata filtering List<Article> articles = vectorTemplate.searchNearestNeighbors( Article.class, queryVector, Map.of( "author", "Otavio Santana", "year", 2026 ), 10 ); Entity Mapping Rule @Id id → native vector ID @Column Vector embedding → native dense vector @Column remaining attributes (content, author, year, category) → payload / metadata Embedding Generation The embedding is generated externally (e.g. LLM, computer vision, recommendation models). Jakarta NoSQL neither generates embeddings nor dictates how they are created. query vector → similarity match payload filters ↓ refined results nearest matching articles Eclipse JNoSQL implementation API
11. Graph Make relationships first-class data GraphTemplateExample.java Core Concept & Use Cases Person READS FOLLOWS Book Person Edge<Person, Book> edge = Edge.source(person) .label("READS") .target(book) .property("since", 2019) .property("format", "digital") .build(); template.edge(edge); Best-fit scenarios: • Social networks • Recommendation systems • Fraud analysis • Knowledge graphs • Dependency networks Vertex → Person, Book ! Edge → READS Traversal Optimization Graph databases excel when relationships have properties. Optimized for deep relationship traversal that becomes cumbersome with repeated relational joins. Eclipse JNoSQL Graph API Edge properties → since, format
12. Jakarta NoSQL 1.1 Richer mapping and more expressive fluent operations Automatic Converters Reduce manual conversion between Java types and database representations Richer Entity Mapping (Map Support) // Map attributes directly to document structures @Column private Map<String, Skill> skills; Richer Mapping Support structured attributes such as maps and nested values Fluent Update API // Expressive & type-safe fluent updates Fluent Update API Compose updates using a fluent programming model template.update(Car.class) .set("available").to(false) .where("type").eq(CarType.CLASSIC) .execute();
13. Jakarta Query One object-oriented query foundation across the Jakarta data ecosystem BEFORE Fragmented Query Models Capabilities defined independently across separate specifications with redundant and divergent syntax. JPQL JD-QL Jakarta Persistence Jakarta Data Jakarta NoSQL JNoSQL UNIFIED APPROACH Unified Query Standard Extracts the shared object-oriented query model into a single foundational specification. Jakarta Query Shared OO Foundation Key Advantages • Single learning curve across specifications • Consistent AST & type-safe metamodel • Seamless portability between persistence layers Common AST • Parser • Metamodel • Dialects
14. JCQL and JPQL Common capabilities for many datastores, richer semantics for relational persistence COMMON SUBSET EXTENDED RELATIONAL Jakarta Common Query Language Jakarta Persistence Query Language JCQL JPQL • Common query capabilities • Richer relational query semantics • Designed to be implementable across multiple datastore technologies • Relevant to Jakarta Persistence • May also be supported by Jakarta Data providers backed by relational persistence • Relevant to Jakarta Data and Jakarta NoSQL • Intentionally avoids relational-only assumptions LANGUAGE RELATIONSHIP JPQL Richer Relational Semantics Extends JCQL with relational features JCQL (Common Subset) Universal baseline across all datastore providers
15. Jakarta NoSQL 1.1 Query API String-based queries, parameter binding, and typed projections Query API & Binding PARAMETERS List<Car> cars = template.query( "FROM Car WHERE type = :type" ).bind("type", CarType.SPORT).result(); Optional<Car> car = template.query( "FROM Car WHERE id = :id" ).bind("id", 42).singleResult(); • QUERY STRING Intuitive string-based query syntax Typed Projections PROJECTION @Projection public record TechCarView( String name, CarType type ) {} List<TechCarView> cars = template.typedQuery( "FROM Car WHERE type = 'SPORT'", TechCarView.class ).result(); • @PROJECTION ANNOTATION • PARAM BINDING Maps custom database shape directly to lightweight DTOs Safe named parameter injection • RECORD-BASED PROJECTION Leverages modern immutable Java Records for clean mapping • LIST RESULT • SINGLE RESULT Retrieve multi-record collections Safe Optional-based retrieval • TYPED QUERY RESULT Strongly-typed template queries without manual mapping