Detecting and Preventing Program Inconsistencies under Database Schema Evolution

Meurice, Loup; Nagy, Csaba; Cleve, Anthony

doi:10.1109/qrs.2016.38

Cited by 22 publications

(7 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As they say, data-intensive systems have heterogeneous architecture divided into multiple parts (software systems, data storage systems, and data), and debt introduced in one part has unwanted effects on other parts as well. A similar phenomenon has been described by several authors [25,29,46], who found that changes in the database or application often remain unpropagated to the other side. In the end, the system's quality decays over time [46].…”

Section: Introductionsupporting

confidence: 80%

FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt

Muse¹,

Nagy²,

Cleve³

et al. 2022

Preprint

Self Cite

View full text Add to dashboard Cite

Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.

show abstract

Section: Introductionsupporting

confidence: 80%

FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt

Muse¹,

Nagy²,

Cleve³

et al. 2022

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

“…However, it is possible to build query dynamically from inside the database (via PERFORM query). We do not handle these kinds of query at the moment but it would be possible to use an approach similar to Meurice et al approach [14].…”

Section: Discussionmentioning

confidence: 99%

“…Meurice et al [14] presented a tool-supported approach that can analyze how the client source code and database schema co-evolved in the past and to simulate a database change to determine client source code locations that would be affected by the change. Additionally, the authors provide strategies (recommendations and warnings) for facing database schema change.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Recommendations for Evolving Relational Databases

Delplanque

Etien

Anquetil

et al. 2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Relational databases play a central role in many information systems. Their schemas contain structural and behavioral entity descriptions. Databases must continuously be adapted to new requirements of a world in constant change while: (1) relational database management systems (RDBMS) do not allow inconsistencies in the schema; (2) stored procedure bodies are not meta-described in RDBMS such as PostgreSQL that consider their bodies as plain text. As a consequence, evaluating the impact of an evolution of the database schema is cumbersome, being essentially manual. We present a semi-automatic approach based on recommendations that can be compiled into a SQL patch fulfilling RDBMS constraints. To support recommendations, we designed a meta-model for relational databases easing computation of change impact. We performed an experiment to validate the approach by reproducing a real evolution on a database. The results of our experiment show that our approach can set the database in the same state as the one produced by the manual evolution in 75% less time.

show abstract

“…First of all, the implicit schema (as described by Fowler ( 2013)) makes evolution in ESSs difficult. Solutions as proposed by Meurice et al (2016) and Maule et al (2008) to analyze the impact of schema changes are not usable, because there is no explicit schema. In contrast to their solution, the change originates in the application and impacts the data in the event store.…”

Section: Schema Evolution In Event Sourced Systemsmentioning

confidence: 99%

An Empirical Characterization of Event Sourced Systems and Their Schema Evolution -- Lessons from Industry

Overeem,

Spoor,

Jansen

et al. 2021

Preprint

View full text Add to dashboard Cite

Event sourced systems are increasing in popularity because they are reliable, flexible, and scalable. In this article, we point a microscope at a software architecture pattern that is rapidly gaining popularity in industry, but has not received as much attention from the scientific community. We do so through constructivist grounded theory, which proves a suitable qualitative method for extracting architectural knowledge from practitioners. Based on the discussion of 19 event sourced systems we explore the rationale for and the context of the event sourcing pattern. A description of the pattern itself and its relation to other patterns as discussed with practitioners is given. The description itself is grounded in the experience of 25 engineers, making it a reliable source for both new practitioners and scientists. We identify five challenges that practitioners experience: event system evolution, the steep learning curve, lack of available technology, rebuilding projections, and data privacy. For the first challenge of event system evolution, we uncover five tactics and solutions that support practitioners in their design choices when developing evolving event sourced systems: versioned events, weak schema, upcasting, in-place transformation, and copy-and-transform.

show abstract

Detecting and Preventing Program Inconsistencies under Database Schema Evolution

Cited by 22 publications

References 28 publications

FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt

FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt

Recommendations for Evolving Relational Databases

An Empirical Characterization of Event Sourced Systems and Their Schema Evolution -- Lessons from Industry

Contact Info

Product

Resources

About