Hi Adam, I'm in touch with the team at Speedment, and I'm hoping to meet them in person pretty soon.
At the current stage, it is hard to say where they want to take their in-memory database in the long run, but here's an unauthoritative and obviously opinionated observation from my side: *Speedment:* The main idea behind Speedment is to run queries using the Java 8 Stream syntax against an in-memory cached version of your RDBMS's data. From what I can tell, this cache can even be distributed, e.g. via Hazelcast. When data is not in the cache, the Stream operations can be transformed to equivalent SQL queries. I've blogged about this operation mapping as well: http://blog.jooq.org/2015/08/13/common-sql-clauses-and-their-equivalents-in-java-8-streams Their claim is that their in-memory processing outperforms anything that hits the backing database. Another claim is that the Stream API is superior to SQL because that's what Java developers are used to do. This matches with philosophies behind APIs like jinq.org (which does even more Stream API to SQL/JPQL transformation), LINQ in .NET, Slick in Scala. *jOOQ:* jOOQ is based on the assumption that 30 years of RDBMS development have made RDBMS extremely sophisticated, also in terms of what they cache internally (buffer caches, server-side and client-side result caches, cursor caches, etc.). When your queries become non-trivial, modern SQL databases heavily rely on cost-based optimisation, they make use of all sorts of meta data (constraints, indexes, histograms, cursor statistics, etc.) to optimise complex queries. I've personally found it hard to beat the Oracle 11g optimiser, e.g. by applying hints. jOOQ is one of the few APIs out there that starts with the assumption that SQL is a good thing - in fact the best thing. There are reasons why SQL is the only surviving and popular 4GL. All other attempts to implement declarative query languages have failed in terms of popularity: QUEL, Datalog, Tutorial D, OQL, OCL, JDOQL, XQuery, LINQ-to-SQL, and I'd even add Cypher and N1QL already to this list - they won't be able to establish themselves next to SQL, unless they merge into SQL. Perhaps alternative languages might have been better integrated into a client language (such as LINQ), but this has always happened at the cost of feature scope and query performance (ironically). *Speedment vs. jOOQ:* The above is a comparison of vision between the two APIs. Speedment tries to implement LINQ for Java via Streams, jOOQ embraces a clean separation of the powerful SQL language and the in-memory client data processing APIs, as documented here: http://blog.jooq.org/2014/07/11/java-8-friday-more-functional-relational-transformation Much like when comparing JPA with jOOQ, this doesn't mean that you cannot do both: http://blog.jooq.org/2015/05/26/type-safe-queries-for-jpas-native-query-api/ Often, it is very useful to be able to implement a (distributed) cache on top of a SQL API, preventing direct access to the backing database for hot, read-only data. And often enough, queries against such a cache are sufficiently trivial, such that a simple filter(), flatMap(), map() chain of operations will suffice. In my opinion, APIs like Speedment (or Hibernate, etc.) should build on top of jOOQ in order to get access to all the 21 currently supported RDBMS in jOOQ. jinq.org already does that. It uses jOOQ as a backing SQL API, and JPA as a backing ORM API. Hope this helps, Lukas 2015-12-12 4:54 GMT+01:00 Adam Zell <[email protected]>: > Hello, > > Has anyone had a chance to compare jOOQ with http://www.speedment.org/? > Their approaches appear similar with perhaps a bigger emphasis on streams > in Speedment. > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
