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
