Database evolution on an orthogonal persistent programming system: A semi-transparent approach

In this paper the problem of the evolution of an object-oriented database in the context of orthogonal persistent programming systems is addressed. We have observed two characteristics in that type of systems that offer particular conditions to implement the evolution in a semi-transparent fashion. That transparency can further be enhanced with the obliviousness provided by the Aspect-Oriented Programming techniques. Was conceived a meta-model and developed a prototype to test the feasibility of our approach. The system allows programs, written to a schema, access semi-transparently to data in other versions of the schema

Evolving database systems : a persistent view

Submitted to POS7 This work was supported in St Andrews by EPSRC Grant GR/J67611 "Delivering the Benefits of Persistence"Orthogonal persistence ensures that information will exist for as long as it is useful, for which it must have the ability to evolve with the growing needs of the application systems that use it. This may involve evolution of the data, meta-data, programs and applications, as well as the users' perception of what the information models. The need for evolution has been well recognised in the traditional (data processing) database community and the cost of failing to evolve can be gauged by the resources being invested in interfacing with legacy systems. Zdonik has identified new classes of application, such as scientific, financial and hypermedia, that require new approaches to evolution. These applications are characterised by their need to store large amounts of data whose structure must evolve as it is discovered by the applications that use it. This requires that the data be mapped dynamically to an evolving schema. Here, we discuss the problems of evolution in these new classes of application within an orthogonally persistent environment and outline some approaches to these problems.Postprin

Evolving NoSQL Databases Without Downtime

NoSQL databases like Redis, Cassandra, and MongoDB are increasingly popular because they are flexible, lightweight, and easy to work with. Applications that use these databases will evolve over time, sometimes necessitating (or preferring) a change to the format or organization of the data. The problem we address in this paper is: How can we support the evolution of high-availability applications and their NoSQL data online, without excessive delays or interruptions, even in the presence of backward-incompatible data format changes? We present KVolve, an extension to the popular Redis NoSQL database, as a solution to this problem. KVolve permits a developer to submit an upgrade specification that defines how to transform existing data to the newest version. This transformation is applied lazily as applications interact with the database, thus avoiding long pause times. We demonstrate that KVolve is expressive enough to support substantial practical updates, including format changes to RedisFS, a Redis-backed file system, while imposing essentially no overhead in general use and minimal pause times during updates.Comment: Update to writing/structur

Variadic genericity through linguistic reflection : a performance evaluation

This work is partially supported by the EPSRC through Grant GR/L32699 “Compliant System Architecture” and by ESPRIT through Working Group EP22552 “PASTEL”.The use of variadic genericity within schema definitions increases the variety of databases that may be captured by a single specification. For example, a class of databases of engineering part objects, in which each database instance varies in the types of the parts and the number of part types, should lend itself to a single definition. However, precise specification of such a schema is beyond the capability of polymorphic type systems and schema definition languages. It is possible to capture such generality by introducing a level of interpretation, in which the variation in types and in the number of fields is encoded in a general data structure. Queries that interpret the encoded information can be written against this general data structure. An alternative approach to supporting such variadic genericity is to generate a precise database containing tailored data structures and queries for each different instance of the virtual schema.1 This involves source code generation and dynamic compilation, a process known as linguistic reflection. The motivation is that once generated, the specific queries may execute more efficiently than their generic counter-parts, since the generic code is “compiled away”. This paper compares the two approaches and gives performance measurements for an example using the persistent languages Napier88 and PJama.Postprin

An introduction to Graph Data Management

A graph database is a database where the data structures for the schema and/or instances are modeled as a (labeled)(directed) graph or generalizations of it, and where querying is expressed by graph-oriented operations and type constructors. In this article we present the basic notions of graph databases, give an historical overview of its main development, and study the main current systems that implement them

A database model for object dynamics.

Object-oriented database systems, Dynamic object re-classification, Object role model, Dynamic class hierarchy, Object migration