Hello,
My activity as a GSoC student comes to its end. Anyways, I'd like to stay.
The reasons are obvious: I like Cayenne, I wanna become an Apache committer,
ORM is useful in 90% business applications. That's why I'm going to publish
here some of my suggestions, things I would like to see improved in Cayenne.
Probably I had to do this before the summer :-) Few of these I have more or
less implemented or worked around in my local version.
1. Reverse engeneering.
I would really like to be able to specify my own naming strategies for
entities, relationships etc. For instance, I hate 'to' prefix. I think it
was introduced to separate DbEntity's attrs' and rels' names. Still,
I'd prefer dropping it for Obj Relationships names. Also we may want to look
at column name. For instance, I have a table PERSON with FATHERID and
MOTHERID. I think getFather() and getMother() methods in my Person class
look much better that getToPerson1() and getToPerson2()!
Something similiar is in CAY-402 and CAY-457. Still, i wouldn't go as far
as implementing removing plurals. Just an interface anyone can implement
would go.
2. Core API.
Generified SelectQuery (and related classes) is the thing Cayenne
definitely misses. I think I've seen some discussion about it, so maybe
someone is currently working on it. This doesn't seem too hard of a task, we
must just look at correct deprecating of present methods, which take Class
as parameter (like SelectQuery constructor).
3. Expression API.
Some improvements must be made with in-memory validation. For instance, if
"count" is an integer field, expression "a='0'" (note quotes) will work in
query (because all DBMS i know have automatic type convertion) and will not
(throw an exception). Also i suffered problems when checking relationships -
there is a bug of comparing PersistentObject to ObjectId somewhere.
4. ROP
I haven't thought of how to implement this yet, but nested contexts are
needed on client side. Most three-tier apps I know have rich GUI (like
Swing), with dialogs for editing data - nested contexts here will be on
their natural place there.
Some thoughts about removing "Client classes have to be available to the
server JVM" limitation. My colleague once shared experience, that if client
and server classes are in same package, client classes are not needed on
server. I.e. client objects are serialized and server objects
are deserialized. If we could somehow tell Hessian that package of classes
may change, that'd solve a problem.
I also have some thoughts about CM usability, but I'm a bit tired of modeler
now, if you know what I mean :-) Maybe later.
I would appreciate any comments and suggestions.
Andrey
This archive was generated by hypermail 2.0.0 : Fri Aug 08 2008 - 07:15:36 EDT