I think we are all agreed that putting Object in the name of a method add no
value. But if we are thinking of designing a fluent query API [1] then perhaps
we should start there with a clean slate and devise a consistent language. When
that is done, it might be easier to bring the ideas back to the existing API.
Our users will not mind changing half a dozen method names once, but will hate
it if we do it one method at a time over the next 6 releases.
How do we go about documenting the next steps? We have lots of ideas, but no
consistent narrative through what we are wanting to do.
Ari
[1] http://martinfowler.com/bliki/FluentInterface.html
On 21/09/11 4:35 PM, Andrus Adamchik wrote:
I agree that the new API is not 100% smooth.. Just like with "localObject",
trying to balance all the considerations is hard:
* we are using "*Object[s]" in other context methods. If we call it "delete",
we'll need to rename those too.
* vararg is an array, so using a singular form looks even less intuitive that
plural for 1 object (I personally think of 1 arg invocation of a vararg method
as a special case of an array, and formally it is)
* preserving both singular and plural forms creates redundancy for no good
reason..
I thought "deleteObjects" will be the most "symmetrical" in regard to the rest of the
methods, and the most technically accurate. But yeah, not ideal... Maybe the next logical step for us should
be stripping "Object[s]" suffix from all methods that have it. It doesn't add any special meaning
anyways.
Andrus
On Sep 21, 2011, at 4:45 AM, Robert Zeigler wrote:
Someone suggested naming it "delete" instead of "deleteObjects". I like that
idea. Then it's grammatically correct for one or more objects, and a bit shorter, to boot. :)
Robert
On Sep 20, 2011, at 9/206:22 PM , Michael Gentry wrote:
I don't have a lot of 3.1-specific tests, but what I ran worked. I
tried another build of the source under Lion, but it still had the
same "problem" in AutoAdapter. I'm just going to ignore that for now.
+1 to the release.
BTW, I'm not sure I like deleteObject() being deprecated. It just
doesn't read/scan as well when deleting a single object to use
deleteObjects(). However, I love that I can specify 3.1M3 in a
pom.xml now. That's a nice change.
Thanks,
mrg
On Mon, Sep 19, 2011 at 9:03 AM, Michael Gentry<[email protected]> wrote:
Hi Andrus,
I just did a build at work and get the same file size as in the .dmg:
find . -name AutoAdapter.class -exec ls -l {} \;
-rw-r--r-- 1 mgentry 8274 Sep 19 08:56
./framework/cayenne-client/target/aggregate/unpack-bin/org/apache/cayenne/dba/AutoAdapter.class
-rw-r--r-- 1 mgentry 8274 Sep 19 08:56
./framework/cayenne-jdk1.5-unpublished/target/classes/org/apache/cayenne/dba/AutoAdapter.class
-rw-r--r-- 1 mgentry 8274 Sep 19 08:56
./framework/cayenne-server/target/aggregate/unpack-bin/org/apache/cayenne/dba/AutoAdapter.class
I'm going to chalk this up to a slight difference in Java on Snow
Leopard vs Lion and continue testing.
Thanks!
mrg
On Mon, Sep 19, 2011 at 2:20 AM, Andrus Adamchik<[email protected]> wrote:
Hi Michael,
Not sure what's the deal with it, but the same class size is produced from the
src build again and again for me:
1. cd ~/work/cayenne-git&& git svn fetch&& git checkout -b 3.1M3 tags/3.1M3
2. # /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src is unarchived src release.
There are no changes in the file contents between the tag checkout and the
release:
~/work/cayenne-git: diff -u -r . ~/Desktop/3.1M3/cayenne-3.1M3-src/
Only in .: .DS_Store
Only in .: .git
Only in /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/: LICENSE.txt
Only in /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/: NOTICE.txt
Only in /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/docs/docbook/main/src:
images
Only in .: eclipse
Only in ./framework/cayenne-jdk1.5-unpublished: derby.log
Only in
/Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/ashwood:
dbutil
Only in
./framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/exp/parser:
.DS_Store
Only in
/Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne:
project
Only in
/Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne:
project
Only in
/Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/testdo:
consttest
Only in
/Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/framework/cayenne-jdk1.5-unpublished/src/test/resources:
i18n
Only in ./framework/cayenne-wocompat-unpublished/src/test/resources/wotests:
.cvsignore
Only in
./framework/cayenne-wocompat-unpublished/src/test/resources/wotests/wotests.xcode:
.cvsignore
Only in /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/itests: cayenne-di-stack
Only in /Users/andrus/Desktop/3.1M3/cayenne-3.1M3-src/itests: itest-common
Only in ./tutorials/tutorial: derby.log
3. cd ~/Desktop/3.1M3/cayenne-3.1M3-src/&& mvnc clean install
~/Desktop/3.1M3/cayenne-3.1M3-src: jar tvf
framework/cayenne-server/target/cayenne-server-3.1M3.jar | grep Auto
2706 Mon Sep 19 09:10:00 EEST 2011 org/apache/cayenne/dba/AutoAdapter$1.class
8274 Mon Sep 19 09:10:00 EEST 2011 org/apache/cayenne/dba/AutoAdapter.class
So the binaries do correspond to the signed version of the release, which
corresponds to the SVN tag contents.
Andrus
On Sep 18, 2011, at 4:50 PM, Michael Gentry wrote:
Hi Andrus,
When I compared the distributed JARs (in the .dmg) vs building the
JARs from the source .tar.gz, I discovered AutoAdapter.class is
different in the server JAR.
Built:
ls -l
cayenne-server/target/aggregate/unpack-bin/org/apache/cayenne/dba/AutoAdapter.class
-rw-r--r-- 1 mrg mrg 8211 Sep 18 09:14
cayenne-server/target/aggregate/unpack-bin/org/apache/cayenne/dba/AutoAdapter.class
Distribution:
jar tvf cayenne-server-3.1M3.jar | grep Auto
2706 Tue Sep 13 20:53:12 EDT 2011 org/apache/cayenne/dba/AutoAdapter$1.class
8274 Tue Sep 13 20:53:12 EDT 2011 org/apache/cayenne/dba/AutoAdapter.class
8211 != 8274. This is the only class that differed in the 4 JARs and
is the first time since I've started comparing the source distribution
to the binary distribution that I've had a class difference. (I
expect MANIFEST.MF and pom.properties to contain different
username/timestamps.) My first guess is that maybe the September 14
commit had slipped into the source:
http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/dba/AutoAdapter.java?r1=1144733&r2=1170516&diff_format=f
However, the source package included the July 9 revision. Any thoughts?
Thanks,
mrg
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
