Proof Of Concept: A fully type safe version of Anorm

[Guillaume Bort]

Hi all,

I have started to work on a proof of concept that brings full type safety to Anorm (for those of you using it).

Here is the demo project:

https://github.com/guillaumebort/anormtyped-demo

Comments are welcome.

--
Guillaume Bort, http://guillaume.bort.fr

[James Roper]

There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I wouldn't mind that at all as long as my schema/sql also worked on H2, because then I could just fire up an in memory database and run the evolutions at compile time, so it would be able to build on any server regardless of the state of the server.

My thoughts would be that it would have to use evolutions, since if you pulled in changes from another developer, and they changed/added something to the schema, the evolutions would have to run before you could even compile the app.

--
 
 

--
James Roper
Software Engineer

Typesafe - The software stack for applications that scale
Twitter: @jroper

[Julien Richard-Foy]

Very interesting work!
What’s the difference with https://github.com/jonifreeman/sqltyped?

[Pascal Voitot Dev]

AFAIK, it's about the same subject but not the same implementation...
sqltyped provides a complete sql parser and uses schema analysis to determine the types in macros.

Guillaume's approach relies purely on the DB server using JDBC PreparedStatement API to determine if the request is valid, what are the parameters and their types etc...

So Guillaume's approach makes the code really short and efficient as it really focuses on RDBMS capabilities about this specific request.

Pascal

On Thu, Jan 17, 2013 at 10:23 AM, Julien Richard-Foy <j...@zenexity.com> wrote:

Very interesting work!
What’s the difference with https://github.com/jonifreeman/sqltyped?

--

[Mariot Chauvin]

Yes I see the same issue here when dealing with database evolutions.

The updated code uses new database scheme and should compile before the evolutions are applied on the database.

But that's a cool POC.

2013/1/17 James Roper <james...@typesafe.com>

--
 
 

--
Mariot Chauvin,
Project Manager at Zenexity C×Ɔ

[Guillaume Bort]

> There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I'm not sure yet :) But it's clear that the only component which is able to validate your SQL statements is the database itself. 

--
 
 

[Pascal Voitot Dev]

On Thu, Jan 17, 2013 at 11:21 AM, Guillaume Bort <guillau...@gmail.com> wrote:

> There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I'm not sure yet :) But it's clear that the only component which is able to validate your SQL statements is the database itself. 

and sqltyped does it also, isn't it?

I think this might seem strange at first to connect to DB at compile-time but it might also be very useful to validate lots of things...

 

On Thu, Jan 17, 2013 at 4:18 AM, James Roper <james...@typesafe.com> wrote:

There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I wouldn't mind that at all as long as my schema/sql also worked on H2, because then I could just fire up an in memory database and run the evolutions at compile time, so it would be able to build on any server regardless of the state of the server.

My thoughts would be that it would have to use evolutions, since if you pulled in changes from another developer, and they changed/added something to the schema, the evolutions would have to run before you could even compile the app.

On Thu, Jan 17, 2013 at 9:50 AM, Guillaume Bort <guillau...@gmail.com> wrote:

Hi all,

I have started to work on a proof of concept that brings full type safety to Anorm (for those of you using it).

Here is the demo project:

https://github.com/guillaumebort/anormtyped-demo

Comments are welcome.

--
Guillaume Bort, http://guillaume.bort.fr

--
 
 

--
James Roper
Software Engineer

Typesafe - The software stack for applications that scale
Twitter: @jroper

--
 
 

--
Guillaume Bort, http://guillaume.bort.fr

--
 
 

[Guillaume Bort]

> and sqltyped does it also, isn't it?

Yes, it does the same.

[Baldur Norddahl]

Den torsdag den 17. januar 2013 04.18.52 UTC+1 skrev James Roper:

There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I have been using sqltyped on a small project and I would have to say yes, because the database schema is part of the program. If you alter the schema, maybe in some way that you expect to cause no trouble, the compiler or IDE will tell you right away if you are wrong.

It is not perfect. You might not discover the problem until you run a clean operation.

As to pulling changes from other developers, I would say compiling before applying database changes is like compiling before resolving merge conflicts. It will succeed only after you have applied the changes correctly, which gives you extra confidence that the merge was good.

On a slight different topic: The template engine could use the same macro tricks and avoid the horrible code generation. It could also support other template engines like Scalate.

Regards,

Baldur

[Julien Tournay]

I think sqltyped also does that: https://github.com/jonifreeman/sqltyped/wiki/User-guide.

[James Roper]

On Thu, Jan 17, 2013 at 9:21 PM, Guillaume Bort <guillau...@gmail.com> wrote:

> There's a tiny detail that you left out... is connecting to the database at compile time a good idea? :)

I'm not sure yet :) But it's clear that the only component which is able to validate your SQL statements is the database itself. 

This is true.  I'm really interested to see whether the benefits of this (which should not be underestimated) outweigh the pains of requiring having a correctly configured database available at compile time (both for devs, and for build servers).  This will vary from developer to developer and organisation to organisation, as different people have different philosophies about how much custom setup a developer should have to do to get a dev environment working.

I'm personally a fan of needing nothing but a JDK to get a fully functional dev environment up and running with one command, but I know there are plenty of other opinions out there.

[Bill Atkins]

I've been happily playing with this for the last day or two - this is really, really nice.

Are there plans to include this in Play itself?

Also, will there ever be a way to integrate this nicely with IDE's? Because TypedSQL is a macro, IntelliJ considers almost any code that works with this to be a compile error.

[James Roper]

On Wed, Feb 6, 2013 at 11:02 AM, Bill Atkins <batk...@gmail.com> wrote:

I've been happily playing with this for the last day or two - this is really, really nice.

Are there plans to include this in Play itself?

Also, will there ever be a way to integrate this nicely with IDE's? Because TypedSQL is a macro, IntelliJ considers almost any code that works with this to be a compile error.

It remains to be seen how IDEs are going to handle macros, currently they don't handle them well at all.  Particularly though with this macro, since it connects to a database and therefore has quite a lot of overhead to compile, it will be interesting to see how well it does/doesn't work.

 

On Wednesday, January 16, 2013 5:50:15 PM UTC-5, Guillaume Bort wrote:

Hi all,

I have started to work on a proof of concept that brings full type safety to Anorm (for those of you using it).

Here is the demo project:

https://github.com/guillaumebort/anormtyped-demo

Comments are welcome.

--
Guillaume Bort, http://guillaume.bort.fr

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Anton Bessonov]

I like it. Personally I find this is painful:

A type safe DSL to generate SQL is a mistake

Some argue that a type safe DSL is better since all your queries are checked by the compiler. Unfortunately the compiler checks your queries based on a meta-model definition that you often write yourself by ‘mapping’ your data structure to the database schema.

There are no guarantees that this meta-model is correct. Even if the compiler says that your code and your queries are correctly typed, it can still miserably fail at runtime because of a mismatch in your actual database definition.

Another question: still no portability between DB's?

--
 
 

-- 
Certified Prince2:2009 Project Manager
Professional Scrum Master I & II
Oracle Certified Expert, Enterprise JavaBeans Developer
Oracle Certified Professional, Java SE 6 Programmer

Now that's a test of the character of an organization.
Of the organizations that are attempting to implement
Scrum probably, 30% - 35% will successfully implement it.
- Ken Schwaber