Hi Andrey,
This is awesome! We very much appreciate your work done so far and
looking forward to working together going forward. Most of your
suggestions is something many people wants to see in Cayenne for some
time, so it would be cool to finally get it done.
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.
+1 for the pluggable naming engine, and making the first alternative
implementation to work like you described, i.e.:
* drop the "to" from to-one relatinship names
* replace "Array" with "s" for to-many.
* use FK as a basis for to-one relationship name
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).
Yes, there were some discussions on the dev list. I made a few
attempts at prototyping it. Unfortunately it is not as trivial as it
seems due to Cayenne support of data rows and generic objects (with
queries created passing entity name as a String). So I got a bit stuck
in my attempts to create the API I like. But definitely let's continue
on that.
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.
We can definitely improve expressions. Let's discuss individual cases
when you are ready to work on that.
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.
+1.
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.
Sure :-) And the Modeler is so much better already :-)
Cheers,
Andrus
