Discussions

News: Announcing Squill: Not Another ORM

  1. Announcing Squill: Not Another ORM (15 messages)

    It is with great pleasure that we announce the first release of Squill. Download it now or check out the quickstart guide, and the step-by-step tutorial. Squill is a slick internal DSL for writing SQL queries in pure Java. It uses the database metadata and generics to catch as many errors as possible during compilation and is almost completely typesafe. At the same time it is designed to allow everything SQL allows you to do, exactly the way SQL is meant to do it. This means that you're encouraged to select only the data you need and no hidden queries are generated for you, leaving you in full control of the query performance. Squill supports database-specific extensions, allowing you to both use advanced features and fully tweak your queries. Squill also has special support for CRUD operations and table relations, adding some sugar over vanilla SQL. A typical Squill query looks like this: ComplaintTable c = new ComplaintTable(); for (Tuple2 tuple2: squill .from(c, c.customer) .where( gt(c.customer.isActive, 0), notNull(c.percentSolved), notNull(c.refoundSum)) .orderBy(desc(c.customer.id)) .selectList( c.customer.lastName, c.percentSolved)) { System.out.println( "Customer " + tuple2.v1 + " has a complaint solved " + tuple2.v2 + "%"); } Squill is a very young project and you can follow (and help) its development by joining the user or developer mailing lists. Yours truly, Juhan Aasaru, Michael Hunger and Jevgeni Kabanov

    Threaded Messages (15)

  2. Looks interesting. Reminds me of good-old Torque (http://db.apache.org/torque/), but as one would expect from a tool developed in 2008, the Squill API is much more "fluent". Some questions: What databases are supported (couldn't find any hint of that on the project homepage)? To what extent does it allow to achieve independence from database specific SQL dialect? (that was one of the purposes of Torque) Does it support "offset" and "limit" concepts? Also on Oracle? "table object" is reusable, but not thread-safe, right?
  3. To what extent does it allow to achieve independence from database specific SQL dialect?
    This is not one of our goals. Vice versa, we encourage writing code for a specific database, using hints, extensions and so on. Squill is a way to write SQL and we do not impose any abstraction layer on top of it. It's quite easy to extend Squill with an abstraction layer, if that's what you want.
    What databases are supported</b</blockquote> Any that supports retrieving metadata through JDBC. All significant ones as far as I know. Since we don't abstract away from databases supporting them is way easier.
    Does it support "offset" and "limit" concepts?
    We haven't started on the database-specific stuff yet, the current release has only SQL92 support. It's trivial to implement, though, and next releases will have support for extensions.
    "table object" is reusable, but not thread-safe, right?
    Yes.
  4. Wow, this looks awesome! Compile-time type safety, classes generated from RDBMS metadata (no need to maintain another schema description), SQL-like syntax, and minimal overhead. I've written my own custom annotation-based ORM library in the past and if I had time I would have rewritten it to me more like this. Can't wait to give this a shot.
  5. JaQu[ Go to top ]

    Looks like JaQu (JavaQuery) as well - damn, I should have patented it :-) Just joking, I hope the idea is successful. The main difference is that JaQu is based on POJOs while Squill creates the classes from the database schema. How can you refactor tables in Squill? Changing the tables in the database and then re-creating the Java classes will break existing Java code. The approach 'refactor Java, and then generate the SQL' is better I think (I know there are problems as well). Squill looks a bit (too(much(nested))). I hope you add the fluent style as well: where(p.age).gt(18) instead of where(gt(p.age, 18)). I guess you can easily do that. What about the anonymous-class-result as inList productInfos = db.from(p).orderBy(p.productId). select(new ProductPrice() {{ productName = p.productName; category = p.category; price = p.unitPrice; }});
  6. Re: JaQu[ Go to top ]

    Looks like JaQu (JavaQuery) as well - damn, I should have patented it :-) J
    Thomas, you're welcome to join us and bring your ideas and code with you :) Squill was started about 1.5 years ago and long before we went public we invited the JEQUEL author Michael Hunger to join us. I know there are a few competing approaches and I'd really wouldn't want to see them competing like the Java we frameworks do. Maybe you could join the Squill mailing list? Your expertise is welcome in any case. As for the decisions, there are very good reasons for them. The SQL->Java was chosen because the database schema is always there and you expect the least effort from your users. The nested static functions are way easier to extend than chaining methods.
  7. Yes but what about SQLJ?[ Go to top ]

    SQLJ solves the same problems but allows you to use native SQL in a Java environment. You don't have to learn a new API, just use SQL. I am surprised that SQLJ is not more widely adopted given the elegance with which it solves these problems. You cannot even get an SQLJ plugin for Eclipse! (please someone tell me I am wrong about that!)
  8. Re: Yes but what about SQLJ?[ Go to top ]

    SQLJ solves the same problems but allows you to use native SQL in a Java environment. You don't have to learn a new API, just use SQL.

    I am surprised that SQLJ is not more widely adopted given the elegance with which it solves these problems. You cannot even get an SQLJ plugin for Eclipse! (please someone tell me I am wrong about that!)
    I think the failure of SQLJ resulted from it being a language extension. Once you put SQLJ code, your code is no longer valid Java. Interestingly, this kind of thing is having a resurgence in popularity under the moniker 'language oriented programming' and similar names. Look at the http://www.theserverside.com/news/thread.tss?thread_id=52240 thread for discussion about it.
  9. 2 cents[ Go to top ]

    I've built a custom ORM like this in the past, and if that's your typical example, then you're not likely to get wide acceptance. The way developers work is to write the queries out in DB SQL, then wrap those up in java code. HQL/EJBQL makes this very easy with the parameters... even though yes, EJB3 and Hibernate have their own long list of issues. Personally for me, any departure away from that mode of operation is a no go, but I wish you the best of luck still. :)
  10. See also: LIQUidFORM[ Go to top ]

    Talking about DSLs and ORM/QL concerns, you may want to take a look at LIQUidFORM, recently posted here too : http://www.theserverside.com/news/thread.tss?thread_id=52054. Slightly different scope - LIQUidFORM is about writing refactor-proof JPA queries -, but some common features, such as typesafety and compile-time errors on hazardous refactoring of the domain model.
  11. sqlorm[ Go to top ]

    I've started another similar project at http://sqlorm.sourceforge.net/ The idea is for the programmer to be able to easily write sql queries with IDE autocompletion and compile-time error checking on db table and column names. It is also straight forward to do simple refactorings as shown in http://sqlorm.sourceforge.net/database_refactoring_made_easy.html -k
  12. I've taken cursory looks at a few of these 'fluent' interfaces for SQL and it seems to me that they have the same fundamental issue that I believe exists with LINQ: not only do they not limit coupling between your code and a database schema, they appear to increase it.
  13. I've taken cursory looks at a few of these 'fluent' interfaces for SQL and it seems to me that they have the same fundamental issue that I believe exists with LINQ: not only do they not limit coupling between your code and a database schema, they appear to increase it.
    Isn't that the whole point of it?
  14. I've taken cursory looks at a few of these 'fluent' interfaces for SQL and it seems to me that they have the same fundamental issue that I believe exists with LINQ: not only do they not limit coupling between your code and a database schema, they appear to increase it.


    Isn't that the whole point of it?
    I guess. I don't really know. I am questioning my own assumptions. My personal take is that if it does increase coupling, then it's solving the wrong problem, at least for my purposes. I can see how this can solve a lot of programming issues but in a larger scope like if you are working with code with embedded SQL strings then this is definitely huge improvement. I think I would lose lot by doing this, however. I use the dynamic nature of SQL loosen the coupling between my code and the database. For example, I currently have an application where I use the same code against very different database schemas. Sure, it's frustrating at times but I think it's worth it overall.
  15. if it increases coupling, then it's solving the wrong problem
    Do you want to add a layer of indirection? That's more work. And if you add a feature you usually have to add it in all layers, so this additional layer slows you down. But if you really want to, you still could: You could map classes to views (instead of tables). Database views (instead of hardcoding queries in the application) sometimes help, because you don't need to re-deploy the application, you can just change the view. But not sure if you talk about that. The problems that Squill, JaQu (and others) solve: - typos are found at compile time - auto-complete support - refactoring support (up to some point) - complete SQL injection protection DRY (don't repeat yourself): you only need to define the tables once (for Squill: in SQL; for other JaQu: in Java).
    I currently have an application where I use the same code against very different database schemas.
    How do you do that? Using views?
  16. >I currently have an application where I use the same code against very different database schemas.

    How do you do that? Using views?
    The queries and updates are passed into the logic. The logic has no concept of where the data comes from. It doesn't even need to be from a database, really. All that is required is that the rows passed to the code have the same set of names and types as expected. Generally this is achieved in the SQL using aliases and rarely with functions.