An Adapter-Based Approach to Co-evolve Generated SQL in M2T Transformations

An Adapter-Based Approach to Co-evolve Generated SQL in M2T

Transformations

Jokin García1, Oscar Díaz1 and Jordi Cabot2

Onekin1

University of the Basque Country, SpainAtlanMod2

Ecole des Mines, Nantes (France)

Thessaloniki - 19th of june, 2014CAiSE

2

Index

Problem statement

Case study

Solution

Evaluation

Conclusions, future work

3

Problem statement: context

Software components on top of platforms Dependencies

Platform evolution is a common situation. DB

API

APIApplication

4

Problem statement: context

Perpetual beta state of platforms.

External dependency

5

Problem statement: contextDomain model M2T Transformation Code

Model refs.(Dynamic)

Embedded platform code(Static)

Transformation code

6

Problem statement: problem

Different versions of the platform leave the code and M2T transformation outdated.

DB DB’Δ

Code

M2T

?

7

Problem statement: solution

Adapter to adapt generated code to new platform

MediaWiki

MediaWiki’

Δ

Code

M2T

Adapter

Code

8

Case study: MediaWiki DB in Wikiwhirl

9

Case study: MediaWiki

Used by Wikipedia and more than 40.000 wikis

In 4,5 years: 171 schema upgrades

10

Case study: MediaWiki DB in Wikiwhirl

Platform-dependent concepts

Refs to domain model

11

Solution

Synchronize the generated code with platform Using adapters at runtime

MediaWiki’

M2T

Adapter

CodeINSERT INTO categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp, cl_type, cl_sortkey_prefix, cl_collation) VALUES (@pageId, ‘Softwareproject’, ‘House_Testing’, (DATE_FORMAT(CURRENT_TIMESTAMP(), ‘%Y%m%d%k%i%s’), ‘page’, ‘’, ‘0’);

print("INSERT into categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp) VALUES (@pageId, '" + categoryTitle + "','" + pageTitle)

New columns “cl_type”, “cl_sortkey_prefix” and“cl_collation”

12

Process outline

Code (MediaWiki DB)

New MediaWiki schema

Old MediaWiki schema

Domainmodel

Differencemodel

New schema model

Old schema model

13

Process outline

Code (MediaWiki DB)

New MediaWiki schema

Old MediaWiki schema

Domainmodel

Differencemodel

New schema model

Old schema model

Don't worry: all in one click

14

Process: Differences between platforms: DB schema

15

Process: Schema Modification Operators (SMO)

SMO % of usage

Change type

Adaptation

Create table 8.9 NBC New comment in the transformation on the existence of this table in the new version

Drop table 3.3 BRC Delete statement associated to the table

Rename table 1.1 BRC Update name

Copy table 2.2 NBC (None)

Add column 38.7 NBC/ BRC

For insert statements: if the attribute is Not Null, add the new column in the statement with a default value (from the DB if there is available or according to the type if there is not)

Drop column 26.4 BRC Delete the column and the value in the statement

Rename column 16 BRC Update name

Copy column 0.4 BRC Like add column case

Move column 1.5 BRC Like drop column + add column cases

16

Process: Adaptation

Plaform-specific, schema-independent

Replace all “println” instructions with “printSQL”

Import “printSQL” library

ZQL extension

For each printSQL invocation: Iterate over the changes reported in the Difference model

Checks if any of the changes impacts the current statement. Needed information to adapt the statement is retrieved and

added to a list of parameters: the statement, affected table, column, …

A function that adapts the statement is called and new statement is printed.

17

Process: Adaptation output

Added columns

Delete tables

Delete columns

18

Roles

Producer Injector for target platform Implement adapter as a library for transformation

Consumer Import adapter library in the transformation Execute the batch

19

Evaluation

Manual Cost = D + P * #Impacts D: Detection time P: Propagation time

Assisted Cost = C + V * #Impacts C: Configuration time V: Verification time

20

Evaluation

21

Dump changes from code to transformation

Assist manual propagation Record generation with change to be done and where (line and column

in the transformation)

M2T transformation

M2T transformation’HOT

print(“select * from …”) printSQL(“select * from …”, line, column)

RECORD:#Added columns cl_type, cl_sortkey_prefix and cl_collation#transformation line: 12, column: 11INSERT INTO categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp, cl_type, cl_sortkey_prefix, cl_collation) VALUES (@pageId, ‘Softwareproject’, ‘House_Testing’, (DATE_FORMAT(CURRENT_TIMESTAMP(), ‘%Y%m%d%k%i%s’), ‘page’, ‘’, ‘0’);

22

Conclusions

Mechanism to adapt code generated by M2T transformations to platform evolution

Apply in a specific case study

Premises: platform instability and transformation coupling

23

Issues and future work

Generalization: other platforms

Methodology for adapter development

24

Questions

[email protected] http://www.onekin.org

Implementation: www.onekin.org/downloads/public/Batch_MofscriptAdaptation.rar

Screencasts: www.onekin.org/downloads/public/screencasts/MOFScript/

25

Process: Adaptation

1- Iterate over the changes reported in the Difference model

2- check that the deleted column's table corresponds with the table name of the statement

3- the statement, the table name and the removed column are added to a list of parameters

4- outputs an SQL statement without the removed column, using a function with the list of parameters that modifies the expression

26

Generate traceability model

Domainmodel

Traceabilitymodel

MOFScript + Adapter

printSQL(statement l,ine, column, print_type)<Transformation: line, column >-><Code: line, column>

Differencemodel

27

Visualize traceability model

Traceabilitymodel

HandyMOF