Our journey from UML/MDD to Scala

macrosHayssam Saleh

Summary

• What this talk is about ?o Why did we choose UML ?o Why did we move from UML to DSLo Our experience in designing a DSL on top of Slick using

Scala macros.

• The macro-based DSL on top of Slick

• Implementationo How macros worko @Model annotation-macro o Dynamic methods statically compiled

Why did we move from UML to scala macros ?

Why UML ?

• Encapsulationo Hide implementation details and expose relevant

abstractions only

• Communicationo Product owner and dev team understand each other

• Qualityo Boilerplate code is generated with respect to the

architect guidelines. Dev team focus on business rules

Why not UML ?

• Lack of efficiencyo Any modification require code regeneration

UML to XMI (20 % - more or less) XMI to code (78% - more or more) Code to bytecode (2% - much less)

o Excessive generation time Code is regenerated for all model entities regardless of

whether they were modifiedo Almost inexistent (real life) collaborative capabilities

Always locked model syndrome Anyone tried to merge UML models on a regular basis ?

• Impedance mismatcho Not all concepts are easily represented in UML

Why Scala macros ?

Why not Scala macros ?

• DSL design is complexo We are used to apply existing patternso Are we used to design grammars ?

• Difficult to develop and maintaino Development at the meta-levelo Hey, we’re working on the AST

The DSL

The DSL Goal

• Allow the product owner and the developer o to share info about the static representation of the

system (The database model in our case)

• The product owner should be able to read it

• The developer should be able to compile it

The good old architecture

http://www.mywebsite.com

ControllerController

Pe

rsisten

ce

laye

rP

ersiste

nce

la

yer

Model

ServiceService

DAODAO

ModelModel

DAODAO

ModelModel

Why Slick as the persistence framework

• Why Slick as a persistence frameworko Because it ’s not an ORM so we’ve got

DBA is happy : No more huge SQL requests that makes SQL auditing difficult

Network is happy : No unnecessary round trip Webserver is happy : no more objects to proxify

€€€ When the customer is happy my boss is happy too

Why Slick as the persistence framework

• What we losto Automatic detection of columns to update

Who cares ?• Unit of I/O defaults to 8K for Postgres, Oracle, SQLServer …

So for most cases (to say the least), updating the whole object has no real impact on performance

o Automatic inserts of dependent objects Our use case focus is on scalable OLTP applications Is it really an issue in OLTP ?

• Do we really want the framework to guess what we’re doing ?• Does it justify the overhead ?

We’ve got to rethink our persistence patterns• We’ve got actors• We’ve got transactions• We’ve got joins

A Slick-macros example

Embedded valueEmbedded value

1..1 relationship1..1 relationship

0..1 relationship0..1 relationship

*..* relationship*..* relationshipConstraintsConstraints

Timestamp all rowsTimestamp all rows

The equivalent Slick Code 1/4

The equivalent Slick Code 2/4

The equivalent Slick Code 3/4

The equivalent Slick Code 4/4

Our UML Model

Slick Mapping generated by the macro

Implementation

Where did the Boilerplate code goes ?

Scala source codeScala source code

Abstract Syntax TreeAbstract Syntax Tree

Java Byte CodeJava Byte Code

RuntimeRuntime

Boilerplate XML / Scala / …

Boilerplate XML / Scala / …

Annotations

Boilerplate code

Outputting the Trees

AST nodes have extractors that definitely help

Dynamic methods Statically compiled

Part 2

Simplify Querying

• Simplify finderso Instead of this

o Write this (pseudo-code)

def macrosdef macros

Simplify Querying

• Simplify updateo Instead of this

o Write this

def macrodef macro Argument names and types are known at call site onlyand still this code remains typechecked at compile timeArgument names and types are known at call site onlyand still this code remains typechecked at compile time

Implementation

A mix of Dynamic and Scala-macros

• First the Slick Query object gets the Dynamic trait

• Since arguments are all named we define the applyDynamicNamed method as a macroo Def macros are applied at call site, we can thus

typecheck at call site against the prefix object.

Conclusion

• As a developero It was almost

A copy/paste task and AST node substitutiono Made easier using the quasiquote feature

• As a usero Much less code to maintaino Reduced time to delivero No runtime overhead

Source code

• Slick-macros @hayssams : http://www.github.com/ebiznext/slick-macros

References

• Scala macros @xeno_by : http://docs.scala-lang.org/overviews/macros/usecases.html

• Slick @szeiger : http://slick.typesafe.com/docs/#talks

• Another source about macros you may find useful http://github.com/ochafik/Scalaxy

Thank you