Post on 19-Jan-2016
description
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