cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: Some more concrete questions about Cayenne
Date Wed, 18 Jan 2012 23:40:34 GMT
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

Mime
View raw message