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

jokin.garcia@ehu.es 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