The New and Improved SQL

Grandi

Model and Data Engineering

et al. 2022

Time-varying JSON data are being used and exchanged in a lot of today's application frameworks like IoT platforms, Web services, cloud computing, online social networks, and mobile systems. However, in the state-of-the-art of JSON data management, there is neither a consensual nor a standard language for updating (i.e., inserting, modifying, and deleting) temporal JSON data, like the TSQL2 or SQL:2016 language for temporal relational data. Moreover, existing JSON-based NoSQL DBMSs (e.g., MongoDB, Couchbase, CouchDB, OrientDB, and Riak) and both commercial DBMSs (e.g., IBM DB2 12, Oracle 19c, and MS SQL Server 2019) and open-source ones (e.g., PostgreSQL 15, and MySQL 8.0) do not provide any support for maintaining temporal JSON data. Also in our previously proposed temporal JSON framework, called τ JSchema, there was no feature for temporal JSON instance update. For these reasons, we propose in this paper a temporal update language, named τ JUpdate (Temporal JUpdate), for JSON data in the τ JSchema environment. We dene it as a temporal extension of our previously introduced non-temporal JSON update language, named JUpdate (JSON Update). Both the syntax and the semantics of the data modication operations of JUpdate have been extended to support temporal aspects. τ JUpdate allows (i) to specify temporal JSON updates in a user-friendly manner, and (ii) to eciently execute them.

Section: Motivating Examplementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

$${\tau }$$JUpdate: A Temporal Update Language for JSON Data

Grandi

Model and Data Engineering

et al. 2022

“…Document stores attract users who engage in rapidly changing requirements taking away the burden of fixing a database schema. Following this trend, the SQL:2016 standard has incorporated JSON into the specification allowing RDBMS to have unstructured data in a single attribute [22]. Therefore, data design for RDBMS also goes beyond strict normalization and might require a cost-based schema design and could benefit from our cost model as well.…”

Section: Introductionmentioning

confidence: 99%

A cost model for random access queries in document stores

et al. 2021

Document stores have become one of the key NoSQL storage solutions. They have been widely adopted in different domains due to their ability to store semi-structured data and expressive query capabilities. However, implementations differ in terms of concrete data storage and retrieval. Unfortunately, a standard framework for data and query optimization for document stores is nonexistent, and only implementationspecific design and query guidelines are used. Hence, the goal of this work is to aid automating the data design for document stores based on query costs instead of generic design rules. For this, we define a generic storage and query cost model based on disk access and memory allocation that allows estimating the impact of design decisions.Since all document stores carry out data operations in memory, we first estimate the memory usage by considering characteristics of the stored documents, their access patterns, and memory management algorithms. Then, using this estimation and metadata storage size, we introduce a cost model for random access queries. We validate our work on two well-known document store implementations: MongoDB and Couchbase. The

Proceedings of the IEEE/ACM 46th International Conference on Software Engineering

“…increasing number of domains. For instance, Structured Query Language (SQL), a canonical example of the declarative paradigm, is the primary query language for most relational database management systems [9,28,69,70]. At the same time, NoSQL databases have been gaining traction.…”

mentioning

confidence: 99%

Object Graph Programming

Thimmaiah,

Lampropoulos,

Rossbach

et al. 2024

We introduce Object Graph Programming (OGO), which enables reading and modifying an object graph (i.e., the entire state of the object heap) via declarative queries. OGO models the objects and their relations in the heap as an object graph thereby treating the heap as a graph database: each node in the graph is an object (e.g., an instance of a class or an instance of a metadata class) and each edge is a relation between objects (e.g., a field of one object references another object). We leverage Cypher, the most popular query language for graph databases, as OGO's query language. Unlike LINQ, which uses collections (e.g., List) as a source of data, OGO views the entire object graph as a single "collection". OGO is ideal for querying collections (just like LINQ), introspecting the runtime system state (e.g., finding all instances of a given class or accessing fields via reflection), and writing assertions that have access to the entire program state. We prototyped OGO for Java in two ways: (a) by translating an object graph into a Neo4j database on which we run Cypher queries, and (b) by implementing our own in-memory graph query engine that directly queries the object heap. We used OGO to rewrite hundreds of statements in large open-source projects into OGO queries. We report our experience and performance of our prototypes.