1. An Adapter-Based Approach to Co-evolve Generated SQL in M2T Transformations Jokin García 1, Oscar Díaz 1 and Jordi Cabot 2 Onekin 1 University of the Basque Country, Spain AtlanMod 2 Ecole des Mines, Nantes (France) Thessaloniki - 19 th of june, 2014 CAiSE

2. 2 Index  Problem statement  Case study  Solution  Evaluation  Conclusions, future work

3. 3 Problem statement: context  Software components on top of platforms  Dependencies  Platform evolution is a common situation.  DB  API API Application

4. 4 Problem statement: context  Perpetual beta state of platforms.  External dependency

5. 5 Problem statement: context Domain modelM2T TransformationCode Model refs. (Dynamic) Embedded platform code (Static) Transformation code

6. 6 Problem statement: problem  Different versions of the platform leave the code and M2T transformation outdated. DBDB’ Δ Code M2T ?

7. 7 Problem statement: solution  Adapter to adapt generated code to new platform Media Wiki Media Wiki’ Δ Code M2T Adapter Code

8. 8 Case study: MediaWiki DB in Wikiwhirl

9. 9 Case study: MediaWiki  Used by Wikipedia and more than 40.000 wikis  In 4,5 years: 171 schema upgrades

10. 10 Case study: MediaWiki DB in Wikiwhirl Platform-dependent concepts Refs to domain model

11. 11 Solution  Synchronize the generated code with platform  Using adapters at runtime Media Wiki’ M2T Adapter Code INSERT 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. 12 Process outline Code (MediaWiki DB) New MediaWiki schema Old MediaWiki schema Domain model Difference model New schema model Old schema model

13. 13 Process outline Code (MediaWiki DB) New MediaWiki schema Old MediaWiki schema Domain model Difference model New schema model Old schema model Don't worry: all in one click

14. 14 Process: Differences between platforms: DB schema

15. 15 Process: Schema Modification Operators (SMO) SMO% of usage Change type Adaptation Create table8.9NBCNew comment in the transformation on the existence of this table in the new version Drop table3.3BRCDelete statement associated to the table Rename table1.1BRCUpdate name Copy table2.2NBC(None) Add column38.7NBC/ 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 column26.4BRCDelete the column and the value in the statement Rename column16BRCUpdate name Copy column0.4BRCLike add column case Move column1.5BRCLike drop column + add column cases

16. 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. 17 Process: Adaptation output Added columns Delete tables Delete columns

18. 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. 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. 20 Evaluation

21. 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: 11 INSERT 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. 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. 23 Issues and future work  Generalization: other platforms  Methodology for adapter development

24. 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. 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. 26 Generate traceability model Domain model Traceability model MOFScript + Adapter printSQL(statement l,ine, column, print_type) -> Difference model

27. 27 Visualize traceability model Traceability model Handy MOF