Changes to the existing API
MetaModel always did a lot to improve the type-safety and correctness of your queries. With version 1.5 we're pushing the query API even further by introducing a query builder that uses a fluent interface, eg. an interface that reads and feels like a regular query expression - except that it's type-safe and compile-time checked.
The API ensures and aids you in building a query by exposing only the currently meaningful methods for your particular query. Here is a simple example:
You can see more examples of the query builder API in the query-related examples in the menu.
MetaModel 1.5 supports the new Excel 2007+ file format (.xlsx extension). As a user you can use the same factory method as with the older Excel spreadsheets.
When reading UTF-8 and UTF-16 text-files (primarily for CSV DataContexts) MetaModel 1.5 will scan the file for a byte order mark (BOM) and adjust the character encoding accordingly, if a BOM is found.
Sometimes it can be costly to do aggregate functions and maybe you're not always interested in the exact measure it generates, but just an approximated value. In MetaModel 1.5 you can set a special FunctionApproximationAllowed flag on a select item and MetaModel will use this to apply optimizations if this is possible.
An example of a situation where it makes sense to use approximation is counting rows in very large (millions of rows) CSV files. Some times you're only interested in getting an rough idea of the amount of rows and this can be generated by sampling the file and counting lines. In such cases approximated aggregates introduce a huge performance improvement, but are of course only applicable where such an approximation is acceptable.
Excel formulas are automatically being evaluated in MetaModel 1.5. This means that your spreadsheet data can contain calculated values expressed as formulas. This feature is automatic and transparent to the user but will prevent the formula string from popping up as a data value.
Previously the schema structure in MetaModel was mutable, meaning that you could change it even though it was being generated based on your datastore.
This was actually an unwanted consequence of a too naive schema structure type system so we changed it in MetaModel 1.5. Basically it should not create problems for any users who have used the API as intended.
Users wanting to manipulate schema structures (eg. for test purposes etc.) will find that there are now special subtypes for this purpose: MutableSchema, MutableTable, MutableColumn etc.
As of version 1.5 the root package of MetaModel has changed from the old dk.eobjects.metamodel to org.eobjects.metamodel. We're painfully aware that this will break backwards compatibility because the new version is no longer a "drop in replacement" but on the other hand, to fix it is extremely simple: Simply do a text-based search and replace, replacing "dk.eobjects.metamodel" with "org.eobjects.metamodel".
All the main types in MetaModel (Schema, Table, Column, Relationship, DataSet, Row etc.) are now interfaces. This means it is significantly easier to write test-code that uses mock objects with MetaModel.
Logging in Java have unfortunately been a complicated matter for a long time. One of the projects that have been gathering a lot of support is slf4j which delivers a way to support multiple logging frameworks without all the (or at least less) hazzle of multiple configurations, jar files etc. Slf4j is a facade for just about any other logging framework, giving you both a simple way to get started and the choice to fine-tune if you need it.
MetaModel 1.5 is now logging completely based on slf4j.
MetaModel 1.5 has way less dependencies than earlier versions. This change was made to make it easier to adopt MetaModel without a lot of concequences for you classpath in big projects.
For databases there have been quite a lot of minor tweaks which help optimize queries and metadata retrieval for various databases. For example: