Some suggestions

[Andrey Razumovsky <ra...@gmail.com>]

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

Re: Some suggestions

[Demetrios Kyriakis <de...@googlemail.com>]

Andrus Adamchik wrote:
> 
> Of course. Not sure how far we can go with an automated engine here. I  
> guess some of naming cleanup may still have to be left to the users.  
> But we can build a basic algorithm for 95% of cases. E.g. check for  
> the ending "s" and change the suffix. Are there amy formal English  
> language rules that would help us in building the algorithm?
> 
As I mentioned in the other reply, this problem is it's already solved, e.g.
in:
https://inflector.dev.java.net/
http://www.csse.monash.edu.au/~damian/papers/HTML/Plurals.html

Demetrios.
-- 
View this message in context: http://www.nabble.com/Some-suggestions-tp18890074p18935322.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.

Re: Some suggestions

[Andrus Adamchik <an...@objectstyle.org>]

On Aug 10, 2008, at 5:49 PM, Michael Gentry wrote:

> On Fri, Aug 8, 2008 at 10:17 AM, Andrus Adamchik <andrus@objectstyle.org 
> > wrote:
>> +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
>
>
> For a to-many, it isn't as simple as adding an "s" at the end for a
> to-many.  At least not in English.  For example, if you have a to-man
> to an Address object, you probably want "getAddresses" and not
> "getAddresss" as the method name.


Of course. Not sure how far we can go with an automated engine here. I  
guess some of naming cleanup may still have to be left to the users.  
But we can build a basic algorithm for 95% of cases. E.g. check for  
the ending "s" and change the suffix. Are there amy formal English  
language rules that would help us in building the algorithm?

Andrus

Re: Some suggestions

[Andrus Adamchik <an...@objectstyle.org>]

On Aug 28, 2008, at 2:00 PM, Andrey Razumovsky wrote:

> Also I agree with Ari about not having it as a runtime dependency, and
>> instead bundling it with the Modeler. There is a lot of value in  
>> the core
>> library to stay lean. Maybe we can access it with reflection from
>> DbGenerator to prevent a compile dependency?
>
>
> We're talking about DbLoader here.

Yep, sorry my bad, I meant DbLoader.

> And of course we will not have
> any dependency from it, because usage of Inflectior is just an
> implementation of naming strategy interface. The question is about  
> where to
> place this class - in core or in modeler. If we design everything  
> for the
> modeler, then why DbLoader class itself is located in the core?

This is considered to be a part of Cayenne core API.

> Still, I agree that we can sacrifice this strategy to keep core  
> library smaller and
> less dependent.
> So, I'm going to initiate uploading the library to main repo and  
> include
> dependency to the modeler.

+1.

Actually we can follow precedents. See "Optional Runtime Dependencies"  
here:

    http://cayenne.apache.org/doc/jar-files-and-dependencies.html

It is listing jars that may be required by runtime if a user wants to  
use a certain feature in a certain configuration. The way this is  
handled in Maven is setting such a jar as a "compile" dependency of  
"cayenne-jdk1.5-unpublished" module, but not the user-visible "cayenne- 
server" module.

Moreover things like commons-dbcp are also set as compile Modeler  
dependencies, achieving the same exact thing we are trying to do here.

Andrus

Re: Some suggestions

[Andrey Razumovsky <ra...@gmail.com>]

>
> Downloads are here:
> https://inflector.dev.java.net/servlets/ProjectDocumentList but I couldn't
> see a maven repository for it.


As I said, project is only on JBoss repo [1].

Also I agree with Ari about not having it as a runtime dependency, and
> instead bundling it with the Modeler. There is a lot of value in the core
> library to stay lean. Maybe we can access it with reflection from
> DbGenerator to prevent a compile dependency?


We're talking about DbLoader here. And of course we will not have
any dependency from it, because usage of Inflectior is just an
implementation of naming strategy interface. The question is about where to
place this class - in core or in modeler. If we design everything for the
modeler, then why DbLoader class itself is located in the core? Still, I
agree that we can sacrifice this strategy to keep core library smaller and
less dependent.
So, I'm going to initiate uploading the library to main repo and include
dependency to the modeler.

[1]
http://mvnrepobrowser.com/artifact-details.html?groupId=org.jvnet&artifactId=inflector

Re: Some suggestions

[Andrus Adamchik <an...@objectstyle.org>]

If we are to add this package, I'd rather we go the route we took with  
jedit-syntax - submit it to the main Maven repo ourselves. Pointing to  
JBoss repo is a bad idea IMO, and has a potential of leading to chaos  
in our builds.

Also I agree with Ari about not having it as a runtime dependency, and  
instead bundling it with the Modeler. There is a lot of value in the  
core library to stay lean. Maybe we can access it with reflection from  
DbGenerator to prevent a compile dependency?

Andrus


On Aug 28, 2008, at 9:46 AM, Aristedes Maniatis wrote:
> On 28/08/2008, at 4:24 PM, Andrey Razumovsky wrote:
>
>> Inflector package is quite lightweight, so I think it's OK if we  
>> add it to
>> core POM (unpublished). I also did not find Inflector in main  
>> Apache repo,
>> but I can see it in JBoss repository. Is it fine if we add that  
>> repo to the
>> project?
>
> From a licensing perspective, we can include it easily since it  
> Apache2 licensed. However it seems to have more of a place in the  
> Modeler app and not in the core Cayenne library which should not be  
> cluttered with these sorts of things. Are we going to have one for  
> every language?
>
> Downloads are here: https://inflector.dev.java.net/servlets/ProjectDocumentList 
>  but I couldn't see a maven repository for it.
>
> Personally I think this is a red herring and really not very  
> important, but if it isn't too much trouble, then I guess it is not  
> a bad thing to have.
>
>
> Ari
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
>

Re: Some suggestions

[Aristedes Maniatis <ar...@ish.com.au>]

On 28/08/2008, at 4:24 PM, Andrey Razumovsky wrote:

> Inflector package is quite lightweight, so I think it's OK if we add  
> it to
> core POM (unpublished). I also did not find Inflector in main Apache  
> repo,
> but I can see it in JBoss repository. Is it fine if we add that repo  
> to the
> project?

 From a licensing perspective, we can include it easily since it  
Apache2 licensed. However it seems to have more of a place in the  
Modeler app and not in the core Cayenne library which should not be  
cluttered with these sorts of things. Are we going to have one for  
every language?

Downloads are here: https://inflector.dev.java.net/servlets/ProjectDocumentList 
  but I couldn't see a maven repository for it.

Personally I think this is a red herring and really not very  
important, but if it isn't too much trouble, then I guess it is not a  
bad thing to have.


Ari



-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Some suggestions

[Andrey Razumovsky <ra...@gmail.com>]

Inflector package is quite lightweight, so I think it's OK if we add it to
core POM (unpublished). I also did not find Inflector in main Apache repo,
but I can see it in JBoss repository. Is it fine if we add that repo to the
project?

2008/8/14, Lachlan Deck <la...@gmail.com>:
>
> On 10/08/2008, at 11:49 PM, Michael Gentry wrote:
>
> On Fri, Aug 8, 2008 at 10:17 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> +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
>>>
>>
>>
>> For a to-many, it isn't as simple as adding an "s" at the end for a
>> to-many.  At least not in English.  For example, if you have a to-man
>> to an Address object, you probably want "getAddresses" and not
>> "getAddresss" as the method name.
>>
>
> net.java.dev.inflector may help for plurals.
>
> with regards,
> --
>
> Lachlan Deck
>
>

Re: Some suggestions

[Lachlan Deck <la...@gmail.com>]

On 10/08/2008, at 11:49 PM, Michael Gentry wrote:

> On Fri, Aug 8, 2008 at 10:17 AM, Andrus Adamchik <andrus@objectstyle.org 
> > wrote:
>> +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
>
>
> For a to-many, it isn't as simple as adding an "s" at the end for a
> to-many.  At least not in English.  For example, if you have a to-man
> to an Address object, you probably want "getAddresses" and not
> "getAddresss" as the method name.

net.java.dev.inflector may help for plurals.

with regards,
--

Lachlan Deck

Re: Some suggestions

[Demetrios Kyriakis <de...@googlemail.com>]

Andrey Razumovsky wrote:
> 
> Pluraling is not such trivial task, and my knowledge of English grammar is
> not so good to implement that myself.
> 
It *is* a very trivial task, as it's has been already solved, e.g. for Java
this library:
https://inflector.dev.java.net/
(it has ASF 2.0 license so it should do it, but there are of course many
other
libraries as well).

Regarding pluralization, I think the most require feature would be to allow
at reverse engineering
to use singular name for the objects:
e.g. when the table is "users", to have automatically the "User" entity,
*not* "Users" entity (how it is now).

Thank you,

Demetrios.

-- 
View this message in context: http://www.nabble.com/Some-suggestions-tp18890074p18916627.html
Sent from the Cayenne - Dev mailing list archive at Nabble.com.

Re: Some suggestions

[Andrey Razumovsky <ra...@gmail.com>]

2008/8/10, Michael Gentry <bl...@gmail.com>:
>
> For a to-many, it isn't as simple as adding an "s" at the end for a
> to-many.  At least not in English.  For example, if you have a to-man
> to an Address object, you probably want "getAddresses" and not
> "getAddresss" as the method name.


I'm also for "Array" suffix. Anyways, one can implement strategy as desired.
Pluraling is not such trivial task, and my knowledge of English grammar is
not so good to implement that myself.

Re: Some suggestions

[Michael Gentry <bl...@gmail.com>]

On Fri, Aug 8, 2008 at 10:17 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> +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


For a to-many, it isn't as simple as adding an "s" at the end for a
to-many.  At least not in English.  For example, if you have a to-man
to an Address object, you probably want "getAddresses" and not
"getAddresss" as the method name.

Re: Some suggestions

[Andrus Adamchik <an...@objectstyle.org>]

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

Re: Some suggestions

[Andrus Adamchik <an...@objectstyle.org>]

On Aug 10, 2008, at 8:47 PM, Andrey Razumovsky wrote:

> For CAY-892 I should probably wait until jEdit is uploaded to
> main repo.

FYI, this just went through the other day:

http://repo1.maven.org/maven2/net/sf/jedit-syntax/jedit-syntax/2.2.2/

Andrus

Re: Some suggestions

[Andrey Razumovsky <ra...@gmail.com>]

Of course I'm still to finish those tasks. I've already submitted
copy/paste. For CAY-892 I should probably wait until jEdit is uploaded to
main repo.

2008/8/10, Aristedes Maniatis <ar...@ish.com.au>:
>
>
> On 08/08/2008, at 9:14 PM, Andrey Razumovsky wrote:
>
> My activity as a GSoC student comes to its end.
>>
>
> Just an update... where are we at with those things marked as not done on
> the wiki:
>
> Tasks:
>
>    * Support for copy/paste of entities/attributes/relationships
>    * Improved ObjRelationship mapping dialog (CAY-1077)
>    * Colored syntax for SQLTemplate (e.g. via jEdit Syntax Package per
> CAY-892)
>
>
> I think CAY-1077 is mostly done. But what about CAY-892? I personally don't
> think it is terribly important, but I know Andrus put jedit into a maven
> repo for use there, so that isn't blocking it any more. And I'm not sure
> about the copy/paste task.
>
>
> Ari Maniatis
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
>

Re: Some suggestions

[Aristedes Maniatis <ar...@ish.com.au>]

On 08/08/2008, at 9:14 PM, Andrey Razumovsky wrote:

> My activity as a GSoC student comes to its end.

Just an update... where are we at with those things marked as not done  
on the wiki:

Tasks:

     * Support for copy/paste of entities/attributes/relationships
     * Improved ObjRelationship mapping dialog (CAY-1077)
     * Colored syntax for SQLTemplate (e.g. via jEdit Syntax Package  
per CAY-892)


I think CAY-1077 is mostly done. But what about CAY-892? I personally  
don't think it is terribly important, but I know Andrus put jedit into  
a maven repo for use there, so that isn't blocking it any more. And  
I'm not sure about the copy/paste task.


Ari Maniatis


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Some suggestions

[Aristedes Maniatis <ar...@ish.com.au>]

On 08/08/2008, at 9:14 PM, Andrey Razumovsky wrote:

> 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.

Your work has been very valuable to Cayenne, and very much  
appreciated. Although working on the modeler might only seem like  
tinkering around the edges of Cayenne, it is very much the first  
impression users get of Cayenne and therefore extremely important to  
the project.


> 1. Reverse engeneering.

If there is a pluggable naming engine, it must have a couple of simple  
prepackaged options available as choices in Cayenne modeler since few  
people will probably go to the trouble of writing their own java  
plugin. There could be a series of checkboxes and options in the  
modeler to make it even easier. This could be taken a further step to  
control the generation of the velocity templates for entity class  
generation. For example we've added:

public static Class<?> getDataTypeForKey(String key)...

to ours since we find it quite useful. It would be great to allow  
users to easily control the naming and options within the entity  
superclass without tinkering with velocity templates which can be a  
bit obscure.


> 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).

I think you'll find that there are as many opinions on this as  
developers :-) but I agree that we should complete the generification  
of Cayenne before 3.0 final is released. I think that SelectQuery is  
one of the last main bits to do. As Andrus said, DataRows was the main  
issue and the conversations (as I recall) revolved around whether you  
choose to perform a DataRow query when you construct the query or when  
you ask for the results.


> 4. ROP
>  I haven't thought of how to implement this yet, but nested contexts  
> are
> needed on client side.

Yes! +1 That would be incredibly useful.


> 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.

Putting client and server entities in the same inheritance hierarchy  
would simplify lots of things for users. For instance, right now it is  
very hard to share validation between client and server classes.


> 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.


My main thought there would be to add documentation to the modeler. I  
think it would be quite simple and is mostly a UI challenge. Each  
relationship, attribute and entity should allow text which then gets  
dumped into javadocs in the generated classes and methods. Really,  
just a bunch of big text areas in the modeler with a convenient way to  
edit them and view them alongside the things they describe. I'm  
thinking that maybe a panel across the bottom. Using the docs in  
tooltips in the modeler (when you hover over an attribute for  
instance) would also be good.

It might be useful to write them out into a separate XML file (not the  
main Cayenne model file) so that they don't have to be exposed to the  
client in ROP for security reasons. Not sure what others think about  
that, since it adds a little complexity.



Anyhow, please don't hesitate to create Jira's for anything you think  
of. That will allow everyone to contribute to the ideas. We want to  
welcome you to working on Cayenne and encourage any ideas that you  
want to develop.


Ari Maniatis



-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A