When referring to type-casting I meant within the ...

2008-08-05T10:29:00.000+02:00

When referring to type-casting I meant within the query. Typically in SQL you can do something like this:

SELECT CAST(myInteger AS VARCHAR) FROM foobar

or

SELECT TO_NUMBER(myStringContainingANumber) FROM foobar

Query Rewriting...

I'd consider looking...

2008-08-04T23:19:00.000+02:00

Query Rewriting...

I'd consider looking around at various other OSS solutions for that piece. Why not interface with something that generates tried and true SQL for the relational database interface? No sense rewriting that from scratch - especially since people have already spent a ton of development time on getting projects like Hibernate (and others) to emit syntactically correct SQL for a variety of databases.

That won't really cover interfacing with CSV, XLS, etc. But the SQL thing is pretty well covered ground at this point.

TOP is also supported in MS-SQL Server:

SELECT TOP 1 * FROM TableName

Type Casting can be tricky business. Many solutions use either a .properties file, or an XML file to specify generic casts of things like varchar -> string, etc. It occurred to me that a good place for that might be the "Schema" object. Perhaps using a fluent style interface one could do the following:

Schema schema = dc.getDefaultSchema();

schema.typeCast(DataType.VARCHAR, java.lang.String).typeCast(...

Could also be useful to utilize the DataContext object there (ask it what the backing store is for the schema - CSV, MySQL, Oracle, etc).

Or something similar. That way the type mapping is established clearly; Also could be done via .properties file - or XML, or via annotations... Depending on how many ways you want people to be able to slice bread.

Possibly the Table object should have a similar interface; allowing for the override of the mappings established at the schema level. So when retrieving values from a table, the code would first check to see if the Table had a type mapping for that type - and if not default to the one specified at the schema level.

Hard to know what the best way to accomplish that might be though - making the DB do the cast, or doing it in Java. With JDBC it has functions like getString(), etc. - so it's possible that such type casting can be done by simply selecting the appropriate method call.

One of the downsides to using constant ints as emums is the compiler won't catch problems for you (from Eff. Java 2nd. ed):

public ststic final int APPLE_FUJI = 0;
public ststic final int APPLE_PIPPIN = 1;
public ststic final int APPLE_GRANNY_SMITH = 2;

public ststic final int ORANGE_NAVEL = 0;
public ststic final int ORANGE_TEMPLE = 0;
public ststic final int ORANGE_BLOOD = 0;

So - now you can do this:

int i = (APPLE_FUJI - ORANGE_TEMPLE) / APPLE_PIPPIN;

You can also do:

if(APPLE_FUJI == ORANGE_NAVEL) {

And you get _no_ type safety - you're able to hand an APPLE to a method that possibly expects an ORANGE (because ultimately they're all just ints, not actual types at all).

Comments on kasper's source: Considering MetaModel functions

When referring to type-casting I meant within the ...

Query Rewriting...I'd consider looking...

Query Rewriting...

I'd consider looking...