cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durchholz, Joachim" <>
Subject RE: Some more concrete questions about Cayenne
Date Thu, 19 Jan 2012 13:54:07 GMT
> Writing a generator for this is very simple since everything
> is in one file

Oh. Is that one XML for all entities?
Or am I misunderstanding something here?
I'd really prefer to have one XML per table.

> The reason we did this is because we maintain our own database
> metadata stored in the database and we wanted to use that.

We'll have to go down a similar route. We'll have to interact with an ERP system that declares
all fields as NUMBER, and keeps metadata about actual valid ranges, precision and scale partly
in tables, partly in text files.
It's going to be fun, of the non-fun type.

> (We also have almost 300 Entities, so modifying them manually
> in the Modeler was out of the question.)

Hmm... that's not a large number.
Seems like Modeler doesn't scale well enough for even medium-sized projects.

We're at just ~50 tables here, so Modeler might still work for us, but I guess we better look
for something textfile-based. Either direct XML editing or some simple source from which we
can generate the XML.

> So it was very simple for us to get all we needed from there.
> I guess it's relatively simple to get this from JDBC
> DatabaseMetadata and use that instead,

Depends. The metadata is defined as a query result, which a very handwavy explanation what
to find in which column.
With the consequence that every RDBMS fills the columns with subtly different kinds of information.
Plus, at least one major vendor (Oracle) is known to return bogus data for many constellations.
You need to know these constellations and infer them from the parameter data that you get.

More fun of the non-fun type ;-)

That said, there are reliable ways to get that kind of data, even from Oracle. You just don't
want to use the DatabaseMetadata API in JDBC, but something vendor-specific. If you need to
get something to work quickly (as opposed to getting it done once and for all), you can manage;
the task becomes even easier if the tables have all been defined along the same set of conventions,
so you don't hit each and every weird constellation of misreported metadata.

> or define it some other way.

This. It seems the ability to merge metadata from multiple sources is essential.
I find myself wanting to specify metadata beyond what the database can give me. Such as enums
and their associations with the strings encoded in the database. Or what kind of formatting
to use for a NUMBER - we want different formats depending on whether the number is an ID (no
separators), a quantity (decimal and fractional separators), or a monetary amount (as quantity
but also a currency symbol). We have DATE fields where 9999-12-31 was defined to be roughly
equivalent to NULL, so the display rules for that field are different from ordinary DATE fields.
And so on and so on.

> After doing that I'm glad we did, as it gives us MUCH
> more control over the whole thing. It's very simple
> to manipulate things, and lets us do things like add
> flattened attributes on all ObjEntities so they all
> implement a common interface,

Sweet :-)

> something that is very cumbersome in the Modeler. It's
> much easier to get stuff exactly how we want them when
> we can program them (after all we are programmers, not
> mouse clickers, right..?)

Hehe, right :-)

> As I said, I really like the map.xml file format, which
> just lists the db-entities, obj-entities, db-relationships
> and obj-relationships. Very easy to generate and manipulate.
> It is very poorly documented, but easy enough to figure out
> based on the Schema and by experimenting in the Modeler and
> see what it produces.

Good to know.

> When we have the map.xml we just use the cgen ant task to
> generate the classes.

Huh. Somehow I never made it to the page documenting the Ant tasks. Probably because I never
properly realized their significance.
Thanks for pointing that out.

> So you don't have to use the modeler, but I wouldn't
> recommend hand-editing.

Okay, I'll keep that in mind.


View raw message