Kasper Sørensen has created a new open source project at eobjects.dk called MetaModel. The project is a common domain model, query engine, and optimizer for different types of datastores, such as relational databases and flat files. MetaModel is a Java library that provides a fluent, object-oriented interface for SQL compliant queries.
MetaModel offers a common domain model for the "datastore" domain. For example, the library provides domain objects such as Table, Column, Query, and DataSet that can be used to query the datasource or even build or alter the structure of the datastore. This model allows you to create and manipulate SQL queries via JDBC against relational databases. It also provides the same query capabilities against CSV and Excel files.
MetaModel's query engine is entirely object oriented. This allows the specification of queries using Java objects instead of arbitrary or potentially error-prone literals. It also provides a level of type-safety in creating the queries.
In discussing the usefulness of the MetaModel library, Sørensen said
MetaModel is not equivalent or a replacement for an O/R mapping tool. It may provide a simpler way to implement database interactions than using straight JDBC.
MetaModel offers a common domain model for the "datastore" domain. For example, the library provides domain objects such as Table, Column, Query, and DataSet that can be used to query the datasource or even build or alter the structure of the datastore. This model allows you to create and manipulate SQL queries via JDBC against relational databases. It also provides the same query capabilities against CSV and Excel files.
MetaModel's query engine is entirely object oriented. This allows the specification of queries using Java objects instead of arbitrary or potentially error-prone literals. It also provides a level of type-safety in creating the queries.
In discussing the usefulness of the MetaModel library, Sørensen said
[I]t enforces a better way of interacting with your data, based on accepted standards and type-safe query-writing. The framework is small and simple, yet powerful, making it easy to use and easy to learn.The project site claimed that the overall goal for MetaModel is to provide a Java API that allows:
- Traversing and building the structure of datastores.
- Executing datastore-neutral queries in a SQL-like manner.
- Provide datastores that do not support queries with a query engine.
- Implement this system for JDBC databases, CSV files and Excel spreadsheets.
- Split single queries into multiple ones that yield the same collective result, enabling powerful performance optimization and grid execution for heavy work loads.
MetaModel is not equivalent or a replacement for an O/R mapping tool. It may provide a simpler way to implement database interactions than using straight JDBC.
Community comments
Differences compared with other ORM tools
by Adrian Costil,
Re: Differences compared with other ORM tools
by Kasper Sørensen,
It would be interesting if it supported SQL/PSM
by Francisco Jose Peredo Noguez,
Re: It would be interesting if it supported SQL/PSM
by Kasper Sørensen,
Re: It would be interesting if it supported SQL/PSM
by Francisco Jose Peredo Noguez,
Re: It would be interesting if it supported SQL/PSM
by Kasper Sørensen,
Differences compared with other ORM tools
by Adrian Costil,
Your message is awaiting moderation. Thank you for participating in the discussion.
What are the major differences between MetaModel and other similar tools like Hibernate/Toplink ?
Re: Differences compared with other ORM tools
by Kasper Sørensen,
Your message is awaiting moderation. Thank you for participating in the discussion.
As stated in the article MetaModel is NOT an O/R mapping tool, so it's not comparable with Hibernate and Toplink.
1. Hibernate is an O/R mapping framework which means that the "input" in Hibernate is your domain model - an object-oriented model of your domain that you wish to map against a database.
2. MetaModel on the other hand is NOT an O/R mapping framework. It is in itself a domain model for the datastore domain. What this means is that it's appropriate to use MetaModel for applications that have the datastores as the domain itself. This is why it's called "MetaModel" - it's a "model of (data) models". You would typically use MetaModel for applications that should work across different datastores (ie. database clients, ETL-tools, database analyzing applications etc.), for example DataCleaner.
It would be interesting if it supported SQL/PSM
by Francisco Jose Peredo Noguez,
Your message is awaiting moderation. Thank you for participating in the discussion.
It would be interesting if it supported SQL/PSM that way it could be used as a foundation to create platform independent stored procedures, after all SQL is not Turing complete, and therefore, sooner or later one needs to write code to transform data using java, and that means having to fetch data from the database, and manipulate it in memory, without taking advantage of the automatic parallelization and indexing offered by the database server.
On the other hand, if MetaModel could be used to specify the algorithms inside stored procedures, and then it could, from the same source code, generate stored procedures in standard SQL/PSM (for DB2), PL/SQL (for Oracle), TSQL (for SqlServer), then it could be used as a fundation to really revolutionize database development (for example, as an engine for an True Relational To Pseudo Relational Mapping like Dataphor or Rel
Re: It would be interesting if it supported SQL/PSM
by Kasper Sørensen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree this would be an interesting feature. As of right now it's not really in our plans though and I'm not quite sure how one would implement such a meta language for stored procedures? I like the idea though and if you're (or anyone) is interested in pursuing it I will do my best to cheer them on and be helpful in any way I can.
Re: It would be interesting if it supported SQL/PSM
by Francisco Jose Peredo Noguez,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have been wondering, how much of this work can be automated? I mean, SQL, for example, has a defined grammar, so, up to a particular point, a lot of the code in the MetaModel API, the classes and methods in java used to describe the SELECTs, could be autogenerated from the grammar definition.
Basically what we have here is an object graph that represents a particular DDL or DML expressions. Why is all that code written by hand and not automatically generated? or is it? and if it is automatically generated... wouldnt it be possible to apply the same algorithm for SQL/PSM? After that it would be a matter of using the Strategy pattern to create different algorithms to generate SQL/PSM (for DB2), PL/SQL (for Oracle), TSQL (for SqlServer), etc.
Re: It would be interesting if it supported SQL/PSM
by Kasper Sørensen,
Your message is awaiting moderation. Thank you for participating in the discussion.
It's not auto-generated because in contrast with parsers MetaModel contains the functionality to actually execute the queries also. Of course let the database do the work when we can, but in some examples this is not possible, for example if you want to query a CSV file and an Excel spreadsheet. Note that you can actually perform advanced querying on eg. an Excel spreadsheet like joining, filtering, ordering etc. in the excact same way that you would when interacting with a database.
Also, SQL is unfortunately not a single grammar, there are lots of dialects and a lot of work has gone into making it compliant with those. MetaModel only contains a subset of the functionality of all SQL dialects and we are continously expanding this functionality but every time we add a new piece of functionality we will make this work uniformly across all supported datastores (for example we are currently investigating how various datastores convert dates to year-numbers, some databases use the YEAR(MY_DATE) function, others EXTRACT(YEAR from MY_DATE) and of course CSV, Excel and XML files don't have this function natively which is why we will also add a java-based query post-processing to match a year-extraction function. I hope this serves as a meaningful example of the challenges (and promises) of MetaModel.