On 19/01/12 2:33 AM, Durchholz, Joachim wrote:
I see Modeler is one of the major sources of "huh?" moments on the list. It's
an additional layer of abstraction between what Cayenne does and what the developer sees,
meaning it can introduce problems (and occasionally does); I'd want to get my feet wet
with Cayenne without that complication.
I am not sure it introduces problems. Sure you can edit XML by hand, but
modeler is a major convenience.
1b) Does Cayenne offer a way to check consistency between XML and a database? (I wouldn't object to
using Modeler for that limited purpose. That might even be a good way to getting used to Modeler's
view of the data model. I guess the answer is "yes", the modeler docs talk about
"Validation of created mappings", but it would be nice to confirm I'm not
misunderstanding something here.)
Look at the reverse engineering options in modeler.
1c) If there's a way to check consistency, are inconsistencies reported in a
way that a Cayenne newbie would understand? Such error messages can be
difficult to generate, they'd need to detail both the involved RDBMS concepts
(tables, fields, lengths, precisions, FKs etc.) and the involved Cayenne
concepts (class definitions, associations). And since an error means these are
out of sync, the error message would need to be as precise as possible about
the nature of the inconsistency, which is no mean feat.
Mainly you will get runtime errors when you try to fetch or save data.
Sometimes they are clear and obvious. Sometimes less so.
2) How would one assign a "field type" with a field in a Cayenne Pojo?
With "field type", I mean things like
123456789012345678901234567890123456789012345678901234567890123456789012
- Associating textual representation with field contents, such as
-- shorthands in the database table, Java enums internally,
longer texts on display
-- or maybe shorthands in the database table, Java Strings internally,
longer texts on display
Cayenne has very nice support for enums. You can map against enums directly in
the model and then define how those enums will be written to the database. This
works well.
- What Swing controls to use for displaying this data
("Renderer" in Swing terminology)
- What Swing controls to use for editing this data
("Editor" in Swing terminology)
Cayenne isn't going to help you with building your UI. Yes, you can fire events
in Swing to fetch and save data back to the entity objects, but you need to
wire that all up yourself and wrap it with a controller that knows how to deal
with Cayenne contexts.
- Validation info: valid ranges; probably a Java interface with
implementations that may or may not use RDBMS length/precision info
Anything you can validate in Java code can be added to the entity classes.
- Possibly association with more than one field
(date/time in two fields but merged into one Java property)
Sure. You can write any of this easily.
(or still two Java properties, but validation etc. spans all of them)
No problem. Validation can easily do this, since you are validating the whole
object, not each attribute.
I see various possible approaches:
2a) The traditional Cayenne approach. Make the entity class a superclass, the
business class a subclass. Entity class properties would have private members
and protected getters/setters, the business class would then use a FieldType
object to delegate public getters/setters to the protected getters/setters.
(FieldType objects would be static and accept entity objects as parameters, so
memory bloat isn't an issue. I'm using a similar construction in my current
Hibernate infrastructure.)
I'm a bit worried about the amount of boilerplate needed in the business class.
In particular for the trivial cases where the DB field is simply handed through
to the business logic (e.g. address fields where the end user should be able to
put in pretty anything they choose as long as it fits the database field).
What boilerplate? That class will be almost empty. And as John says, you can
customise the velocity templates any way you like.
2b) Use delegation instead of subclassing. The issues are essentially the same,
except the getters/setters of the entity class wouldn't have to be
package-private or public instead of protected.
Are there other issues that I should be aware of?
2c) Since I'm not too dependent on Modeler, I might merge entity and business
class.
I'm not sure that such a merge has any advantages; does anybody have seen this
tried? Stories of failure and success equally interesting here.
I have to admit I don't expect success, merging abstractions usually doesn't
work well in the long term; losing the option to use Modeler's code generation
later when we're more confident in it is a strong point agains that route, too.
Still, I'd like to know how much water this assessment holds.
You are making this hard for yourself without any obvious gain.
2d) Anything I haven't thought of. Different ways to use Java reflection, a
Modeler option I'm not aware of that does all these things out of the box,
whatever.
3) How do I do cascading?
I have seen some mention of this in the docs but haven't found a comprehensive
description.
Do you mean cascading of deletes across relations? Or something else? Perhaps
you want to play with the event listeners in the modeler. That might be what
you are after.
Cheers
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
