New features
- Fluent query builder 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:
DataContext dc = ...;
Query q = dc.query().from(projects).selectCount().and(community).where(license).equals("oss").groupBy(community).toQuery();
You can see more examples of the query builder API in the query-related examples in the menu.
- Support for Excel 2007+ spreadsheets
-
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.
- Detection and usage of byte order mark (BOM) in UTF-* files
-
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.
- Approximated aggregate functions
-
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.
- Support for Excel formulas
-
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.
Changes to the existing API
- Immutable schema structures
-
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.
- Root package rename
-
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".
- Everything as an interface
-
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.
- Switch from commons-logging to slf4j
-
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.
- Fewer external dependencies
-
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.
- Enhancements and optimization of native query translation
-
For databases there have been quite a lot of minor tweaks which help optimize
queries and metadata retrieval for various databases. For example:
- Escaping of strings in WHERE and HAVING clauses was significantly
improved and works across different SQL dialects.
- In Microsoft SQL Server, we are now using the schema name "dbo" as the
default schema if no better candidates are found.
Bugfixes
- Handling of InputStream with CSV content
- A bug was fixed related to temporary storage of an InputStream CSV content.
- Qualified labels with dots in table names
- Some schema structure elements, such as tables, can in rare circumstances
contain dots in their names. The parser for qualified labels of tables and columns
was not aware of this and thus interpreted any dots as delimitors, which caused it
to not resolve qualified labels correctly.
- Qualified labels for schemas without a name
- In some circumstances a schema will have no name. Therefore the qualified
label for an item within that schema will not have a prepended schema name. The
qualified label parser was not aware of this, and that has been fixed.
- Inclusion of columns in subquery filter items
- A bug was fixed in MetaModel's internal query engine, which was related
to evaluation of columns that are only referenced in subquery filter items
(WHERE or HAVING clause).
