You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2014/09/05 13:07:52 UTC
Re: 3.1-final test scoresheet
One possible last minute change is un-deprecating ObjectContext.deleteObject(..). It can easily coexist with 'deleteObjects', and getting rid of it was not the best idea on my part.
Andrus
On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> In preparation to the 3.1-final vote, I ran the same set of tests as we did for RC1. All tests are on Java 1.6 unless specified otherwise. You can compare it with the previous results at http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything is the same, so the latest 3.1 changes didn’t break anything obvious. There’s one less test failure on Oracle, which is related to my improved Oracle setup, rather than anything in Cayenne. Feel free to replicate the results in your own environment.
>
> rat: PASSED
> hsql: PASSED
> h2: PASSED
> derby: PASSED
> derby/Java7: PASSED
> mysql 5.0: [1] PASSED
> mysql 5.6: [2] PASSED
> sqlserver [3] PASSED
> postgresql: Failures: 1 testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
> oracle 11: Failed tests:
> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>
> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
>
> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
>
> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M lower_case_table_names = 1
>
> [3] SQL Server 2005 Expression config: collation - SQL_Latin1_general_CP1_CS_AS
>
> Andrus
Re: 3.1-final test scoresheet
Posted by Michael Gentry <mg...@masslight.net>.
My bad. I was trying to process that e-mail, fix a bug, and a few other
things before a meeting and fired it off without thinking through it fully.
Not the first thing I've bobbled today. :-)
So yes, 'protected' is great.
Thanks!
mrg
On Tue, Sep 9, 2014 at 10:47 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> It is the default scope that limits access to a package. "protected"
> limits access to subclasses no matter their location. So that should work,
> and still indicate that the class is not for instantiation.
>
> Andrus
>
> On Sep 9, 2014, at 5:37 PM, Michael Gentry <mg...@masslight.net> wrote:
>
> > If the method is changed to protected, any subclass would have to reside
> in
> > the same package space, which seems undesirable to me.
> >
> > Here is how Apache Commons does it:
> >
> > public class FileUtils {
> >
> >
> > /**
> >
> > * Instances should NOT be constructed in standard programming.
> >
> > */
> >
> > public FileUtils() {
> >
> > super();
> >
> > }
> > ...
> >
> > public class StringUtils {
> > ...
> >
> > public StringUtils() {
> >
> > super();
> >
> > }
> > ...
> >
> > mrg
> >
> >
> > On Tue, Sep 9, 2014 at 2:10 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> >
> >> Usually we have private constructors for statics only classes (as is the
> >> case here). It sort of indicates it to the end users that the class is
> not
> >> supposed to be instantiated. While technically you won't get true
> >> polymorphism by inheriting from statics-only class in Java, it may
> still be
> >> beneficial to add more static methods to a subclass I guess. So how
> about
> >> we change that to protected? (in 3.2?)
> >>
> >> Andrus
> >>
> >>
> >> On Sep 8, 2014, at 11:18 PM, Michael Gentry <mg...@masslight.net>
> wrote:
> >>> FWIW, I tried to extend the Cayenne class (we had a discussion about
> that
> >>> ages ago) and even though it is no longer final, it cannot be extended
> >>> because of the private constructor. Should we remove the private
> >>> constructor to allow "subclassing" like Apache Commons allows?
> >>>
> >>> Thanks,
> >>>
> >>> mrg
> >>>
> >>>
> >>> On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <
> andrus@objectstyle.org>
> >>> wrote:
> >>>
> >>>> Done.
> >>>>
> >>>> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now
> >> that
> >>>> we are moving in the direction of richer user-facing APIs, builders,
> >> etc,
> >>>> so this only makes sense to add this method back.
> >>>>
> >>>> Andrus
> >>>>
> >>>>
> >>>> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net>
> >> wrote:
> >>>>> I seem to recall a discussion on that particular method years ago,
> but
> >>>>> don't remember the details (I'd have to go back and find it).
> >>>>>
> >>>>> I'm fine with having deleteObject() just turn around and call
> >>>>> deleteObjects() because it makes the calling code read better, even
> at
> >>>> the
> >>>>> "expense" of cluttering up the API (although this isn't much,
> really).
> >>>>>
> >>>>> mrg
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <
> >> andrus@objectstyle.org>
> >>>>> wrote:
> >>>>>
> >>>>>> One possible last minute change is un-deprecating
> >>>>>> ObjectContext.deleteObject(..). It can easily coexist with
> >>>> 'deleteObjects',
> >>>>>> and getting rid of it was not the best idea on my part.
> >>>>>>
> >>>>>> Andrus
> >>>>>>
> >>>>>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <
> andrus@objectstyle.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> In preparation to the 3.1-final vote, I ran the same set of tests
> as
> >> we
> >>>>>> did for RC1. All tests are on Java 1.6 unless specified otherwise.
> You
> >>>> can
> >>>>>> compare it with the previous results at
> >>>>>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially
> everything
> >>>> is
> >>>>>> the same, so the latest 3.1 changes didn’t break anything obvious.
> >>>> There’s
> >>>>>> one less test failure on Oracle, which is related to my improved
> >> Oracle
> >>>>>> setup, rather than anything in Cayenne. Feel free to replicate the
> >>>> results
> >>>>>> in your own environment.
> >>>>>>>
> >>>>>>> rat: PASSED
> >>>>>>> hsql: PASSED
> >>>>>>> h2: PASSED
> >>>>>>> derby: PASSED
> >>>>>>> derby/Java7: PASSED
> >>>>>>> mysql 5.0: [1] PASSED
> >>>>>>> mysql 5.6: [2] PASSED
> >>>>>>> sqlserver [3] PASSED
> >>>>>>> postgresql: Failures: 1
> >>>>>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> oracle 11: Failed tests:
> >>>>>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>>>
> >>>>>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
> >>>>>>>
> >>>>>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
> >>>>>>>
> >>>>>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
> >>>>>> lower_case_table_names = 1
> >>>>>>>
> >>>>>>> [3] SQL Server 2005 Expression config: collation -
> >>>>>> SQL_Latin1_general_CP1_CS_AS
> >>>>>>>
> >>>>>>> Andrus
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: 3.1-final test scoresheet
Posted by Andrus Adamchik <an...@objectstyle.org>.
It is the default scope that limits access to a package. "protected" limits access to subclasses no matter their location. So that should work, and still indicate that the class is not for instantiation.
Andrus
On Sep 9, 2014, at 5:37 PM, Michael Gentry <mg...@masslight.net> wrote:
> If the method is changed to protected, any subclass would have to reside in
> the same package space, which seems undesirable to me.
>
> Here is how Apache Commons does it:
>
> public class FileUtils {
>
>
> /**
>
> * Instances should NOT be constructed in standard programming.
>
> */
>
> public FileUtils() {
>
> super();
>
> }
> ...
>
> public class StringUtils {
> ...
>
> public StringUtils() {
>
> super();
>
> }
> ...
>
> mrg
>
>
> On Tue, Sep 9, 2014 at 2:10 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> Usually we have private constructors for statics only classes (as is the
>> case here). It sort of indicates it to the end users that the class is not
>> supposed to be instantiated. While technically you won't get true
>> polymorphism by inheriting from statics-only class in Java, it may still be
>> beneficial to add more static methods to a subclass I guess. So how about
>> we change that to protected? (in 3.2?)
>>
>> Andrus
>>
>>
>> On Sep 8, 2014, at 11:18 PM, Michael Gentry <mg...@masslight.net> wrote:
>>> FWIW, I tried to extend the Cayenne class (we had a discussion about that
>>> ages ago) and even though it is no longer final, it cannot be extended
>>> because of the private constructor. Should we remove the private
>>> constructor to allow "subclassing" like Apache Commons allows?
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>
>>>> Done.
>>>>
>>>> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now
>> that
>>>> we are moving in the direction of richer user-facing APIs, builders,
>> etc,
>>>> so this only makes sense to add this method back.
>>>>
>>>> Andrus
>>>>
>>>>
>>>> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net>
>> wrote:
>>>>> I seem to recall a discussion on that particular method years ago, but
>>>>> don't remember the details (I'd have to go back and find it).
>>>>>
>>>>> I'm fine with having deleteObject() just turn around and call
>>>>> deleteObjects() because it makes the calling code read better, even at
>>>> the
>>>>> "expense" of cluttering up the API (although this isn't much, really).
>>>>>
>>>>> mrg
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <
>> andrus@objectstyle.org>
>>>>> wrote:
>>>>>
>>>>>> One possible last minute change is un-deprecating
>>>>>> ObjectContext.deleteObject(..). It can easily coexist with
>>>> 'deleteObjects',
>>>>>> and getting rid of it was not the best idea on my part.
>>>>>>
>>>>>> Andrus
>>>>>>
>>>>>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
>>>>>> wrote:
>>>>>>
>>>>>>> In preparation to the 3.1-final vote, I ran the same set of tests as
>> we
>>>>>> did for RC1. All tests are on Java 1.6 unless specified otherwise. You
>>>> can
>>>>>> compare it with the previous results at
>>>>>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
>>>> is
>>>>>> the same, so the latest 3.1 changes didn’t break anything obvious.
>>>> There’s
>>>>>> one less test failure on Oracle, which is related to my improved
>> Oracle
>>>>>> setup, rather than anything in Cayenne. Feel free to replicate the
>>>> results
>>>>>> in your own environment.
>>>>>>>
>>>>>>> rat: PASSED
>>>>>>> hsql: PASSED
>>>>>>> h2: PASSED
>>>>>>> derby: PASSED
>>>>>>> derby/Java7: PASSED
>>>>>>> mysql 5.0: [1] PASSED
>>>>>>> mysql 5.6: [2] PASSED
>>>>>>> sqlserver [3] PASSED
>>>>>>> postgresql: Failures: 1
>>>>>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> oracle 11: Failed tests:
>>>>>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>>
>>>>>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
>>>>>>>
>>>>>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
>>>>>>>
>>>>>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
>>>>>> lower_case_table_names = 1
>>>>>>>
>>>>>>> [3] SQL Server 2005 Expression config: collation -
>>>>>> SQL_Latin1_general_CP1_CS_AS
>>>>>>>
>>>>>>> Andrus
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: 3.1-final test scoresheet
Posted by Michael Gentry <mg...@masslight.net>.
If the method is changed to protected, any subclass would have to reside in
the same package space, which seems undesirable to me.
Here is how Apache Commons does it:
public class FileUtils {
/**
* Instances should NOT be constructed in standard programming.
*/
public FileUtils() {
super();
}
...
public class StringUtils {
...
public StringUtils() {
super();
}
...
mrg
On Tue, Sep 9, 2014 at 2:10 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Usually we have private constructors for statics only classes (as is the
> case here). It sort of indicates it to the end users that the class is not
> supposed to be instantiated. While technically you won't get true
> polymorphism by inheriting from statics-only class in Java, it may still be
> beneficial to add more static methods to a subclass I guess. So how about
> we change that to protected? (in 3.2?)
>
> Andrus
>
>
> On Sep 8, 2014, at 11:18 PM, Michael Gentry <mg...@masslight.net> wrote:
> > FWIW, I tried to extend the Cayenne class (we had a discussion about that
> > ages ago) and even though it is no longer final, it cannot be extended
> > because of the private constructor. Should we remove the private
> > constructor to allow "subclassing" like Apache Commons allows?
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> >
> >> Done.
> >>
> >> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now
> that
> >> we are moving in the direction of richer user-facing APIs, builders,
> etc,
> >> so this only makes sense to add this method back.
> >>
> >> Andrus
> >>
> >>
> >> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net>
> wrote:
> >>> I seem to recall a discussion on that particular method years ago, but
> >>> don't remember the details (I'd have to go back and find it).
> >>>
> >>> I'm fine with having deleteObject() just turn around and call
> >>> deleteObjects() because it makes the calling code read better, even at
> >> the
> >>> "expense" of cluttering up the API (although this isn't much, really).
> >>>
> >>> mrg
> >>>
> >>>
> >>>
> >>> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <
> andrus@objectstyle.org>
> >>> wrote:
> >>>
> >>>> One possible last minute change is un-deprecating
> >>>> ObjectContext.deleteObject(..). It can easily coexist with
> >> 'deleteObjects',
> >>>> and getting rid of it was not the best idea on my part.
> >>>>
> >>>> Andrus
> >>>>
> >>>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
> >>>> wrote:
> >>>>
> >>>>> In preparation to the 3.1-final vote, I ran the same set of tests as
> we
> >>>> did for RC1. All tests are on Java 1.6 unless specified otherwise. You
> >> can
> >>>> compare it with the previous results at
> >>>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
> >> is
> >>>> the same, so the latest 3.1 changes didn’t break anything obvious.
> >> There’s
> >>>> one less test failure on Oracle, which is related to my improved
> Oracle
> >>>> setup, rather than anything in Cayenne. Feel free to replicate the
> >> results
> >>>> in your own environment.
> >>>>>
> >>>>> rat: PASSED
> >>>>> hsql: PASSED
> >>>>> h2: PASSED
> >>>>> derby: PASSED
> >>>>> derby/Java7: PASSED
> >>>>> mysql 5.0: [1] PASSED
> >>>>> mysql 5.6: [2] PASSED
> >>>>> sqlserver [3] PASSED
> >>>>> postgresql: Failures: 1
> >>>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> oracle 11: Failed tests:
> >>>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>>>
> >>>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
> >>>>>
> >>>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
> >>>>>
> >>>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
> >>>> lower_case_table_names = 1
> >>>>>
> >>>>> [3] SQL Server 2005 Expression config: collation -
> >>>> SQL_Latin1_general_CP1_CS_AS
> >>>>>
> >>>>> Andrus
> >>>>
> >>>>
> >>
> >>
>
>
Re: 3.1-final test scoresheet
Posted by Mike Kienenberger <mk...@gmail.com>.
+1 to making the constructor protected.
On Tue, Sep 9, 2014 at 2:10 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Usually we have private constructors for statics only classes (as is the case here). It sort of indicates it to the end users that the class is not supposed to be instantiated. While technically you won't get true polymorphism by inheriting from statics-only class in Java, it may still be beneficial to add more static methods to a subclass I guess. So how about we change that to protected? (in 3.2?)
>
> Andrus
>
>
> On Sep 8, 2014, at 11:18 PM, Michael Gentry <mg...@masslight.net> wrote:
>> FWIW, I tried to extend the Cayenne class (we had a discussion about that
>> ages ago) and even though it is no longer final, it cannot be extended
>> because of the private constructor. Should we remove the private
>> constructor to allow "subclassing" like Apache Commons allows?
>>
>> Thanks,
>>
>> mrg
>>
>>
>> On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> Done.
>>>
>>> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now that
>>> we are moving in the direction of richer user-facing APIs, builders, etc,
>>> so this only makes sense to add this method back.
>>>
>>> Andrus
>>>
>>>
>>> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net> wrote:
>>>> I seem to recall a discussion on that particular method years ago, but
>>>> don't remember the details (I'd have to go back and find it).
>>>>
>>>> I'm fine with having deleteObject() just turn around and call
>>>> deleteObjects() because it makes the calling code read better, even at
>>> the
>>>> "expense" of cluttering up the API (although this isn't much, really).
>>>>
>>>> mrg
>>>>
>>>>
>>>>
>>>> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
>>>> wrote:
>>>>
>>>>> One possible last minute change is un-deprecating
>>>>> ObjectContext.deleteObject(..). It can easily coexist with
>>> 'deleteObjects',
>>>>> and getting rid of it was not the best idea on my part.
>>>>>
>>>>> Andrus
>>>>>
>>>>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
>>>>> wrote:
>>>>>
>>>>>> In preparation to the 3.1-final vote, I ran the same set of tests as we
>>>>> did for RC1. All tests are on Java 1.6 unless specified otherwise. You
>>> can
>>>>> compare it with the previous results at
>>>>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
>>> is
>>>>> the same, so the latest 3.1 changes didn't break anything obvious.
>>> There's
>>>>> one less test failure on Oracle, which is related to my improved Oracle
>>>>> setup, rather than anything in Cayenne. Feel free to replicate the
>>> results
>>>>> in your own environment.
>>>>>>
>>>>>> rat: PASSED
>>>>>> hsql: PASSED
>>>>>> h2: PASSED
>>>>>> derby: PASSED
>>>>>> derby/Java7: PASSED
>>>>>> mysql 5.0: [1] PASSED
>>>>>> mysql 5.6: [2] PASSED
>>>>>> sqlserver [3] PASSED
>>>>>> postgresql: Failures: 1
>>>>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> oracle 11: Failed tests:
>>>>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>>
>>>>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
>>>>>>
>>>>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
>>>>>>
>>>>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
>>>>> lower_case_table_names = 1
>>>>>>
>>>>>> [3] SQL Server 2005 Expression config: collation -
>>>>> SQL_Latin1_general_CP1_CS_AS
>>>>>>
>>>>>> Andrus
>>>>>
>>>>>
>>>
>>>
>
Re: 3.1-final test scoresheet
Posted by Andrus Adamchik <an...@objectstyle.org>.
Usually we have private constructors for statics only classes (as is the case here). It sort of indicates it to the end users that the class is not supposed to be instantiated. While technically you won't get true polymorphism by inheriting from statics-only class in Java, it may still be beneficial to add more static methods to a subclass I guess. So how about we change that to protected? (in 3.2?)
Andrus
On Sep 8, 2014, at 11:18 PM, Michael Gentry <mg...@masslight.net> wrote:
> FWIW, I tried to extend the Cayenne class (we had a discussion about that
> ages ago) and even though it is no longer final, it cannot be extended
> because of the private constructor. Should we remove the private
> constructor to allow "subclassing" like Apache Commons allows?
>
> Thanks,
>
> mrg
>
>
> On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> Done.
>>
>> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now that
>> we are moving in the direction of richer user-facing APIs, builders, etc,
>> so this only makes sense to add this method back.
>>
>> Andrus
>>
>>
>> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net> wrote:
>>> I seem to recall a discussion on that particular method years ago, but
>>> don't remember the details (I'd have to go back and find it).
>>>
>>> I'm fine with having deleteObject() just turn around and call
>>> deleteObjects() because it makes the calling code read better, even at
>> the
>>> "expense" of cluttering up the API (although this isn't much, really).
>>>
>>> mrg
>>>
>>>
>>>
>>> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>
>>>> One possible last minute change is un-deprecating
>>>> ObjectContext.deleteObject(..). It can easily coexist with
>> 'deleteObjects',
>>>> and getting rid of it was not the best idea on my part.
>>>>
>>>> Andrus
>>>>
>>>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
>>>> wrote:
>>>>
>>>>> In preparation to the 3.1-final vote, I ran the same set of tests as we
>>>> did for RC1. All tests are on Java 1.6 unless specified otherwise. You
>> can
>>>> compare it with the previous results at
>>>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
>> is
>>>> the same, so the latest 3.1 changes didn’t break anything obvious.
>> There’s
>>>> one less test failure on Oracle, which is related to my improved Oracle
>>>> setup, rather than anything in Cayenne. Feel free to replicate the
>> results
>>>> in your own environment.
>>>>>
>>>>> rat: PASSED
>>>>> hsql: PASSED
>>>>> h2: PASSED
>>>>> derby: PASSED
>>>>> derby/Java7: PASSED
>>>>> mysql 5.0: [1] PASSED
>>>>> mysql 5.6: [2] PASSED
>>>>> sqlserver [3] PASSED
>>>>> postgresql: Failures: 1
>>>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> oracle 11: Failed tests:
>>>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>>>
>>>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
>>>>>
>>>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
>>>>>
>>>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
>>>> lower_case_table_names = 1
>>>>>
>>>>> [3] SQL Server 2005 Expression config: collation -
>>>> SQL_Latin1_general_CP1_CS_AS
>>>>>
>>>>> Andrus
>>>>
>>>>
>>
>>
Re: 3.1-final test scoresheet
Posted by Michael Gentry <mg...@masslight.net>.
FWIW, I tried to extend the Cayenne class (we had a discussion about that
ages ago) and even though it is no longer final, it cannot be extended
because of the private constructor. Should we remove the private
constructor to allow "subclassing" like Apache Commons allows?
Thanks,
mrg
On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Done.
>
> Once I was a big fan of terse non-redundant APIs. Not anymore :) Now that
> we are moving in the direction of richer user-facing APIs, builders, etc,
> so this only makes sense to add this method back.
>
> Andrus
>
>
> On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net> wrote:
> > I seem to recall a discussion on that particular method years ago, but
> > don't remember the details (I'd have to go back and find it).
> >
> > I'm fine with having deleteObject() just turn around and call
> > deleteObjects() because it makes the calling code read better, even at
> the
> > "expense" of cluttering up the API (although this isn't much, really).
> >
> > mrg
> >
> >
> >
> > On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> >
> >> One possible last minute change is un-deprecating
> >> ObjectContext.deleteObject(..). It can easily coexist with
> 'deleteObjects',
> >> and getting rid of it was not the best idea on my part.
> >>
> >> Andrus
> >>
> >> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
> >> wrote:
> >>
> >>> In preparation to the 3.1-final vote, I ran the same set of tests as we
> >> did for RC1. All tests are on Java 1.6 unless specified otherwise. You
> can
> >> compare it with the previous results at
> >> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
> is
> >> the same, so the latest 3.1 changes didn’t break anything obvious.
> There’s
> >> one less test failure on Oracle, which is related to my improved Oracle
> >> setup, rather than anything in Cayenne. Feel free to replicate the
> results
> >> in your own environment.
> >>>
> >>> rat: PASSED
> >>> hsql: PASSED
> >>> h2: PASSED
> >>> derby: PASSED
> >>> derby/Java7: PASSED
> >>> mysql 5.0: [1] PASSED
> >>> mysql 5.6: [2] PASSED
> >>> sqlserver [3] PASSED
> >>> postgresql: Failures: 1
> >> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> oracle 11: Failed tests:
> >>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >>>
> >>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
> >>>
> >>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
> >>>
> >>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
> >> lower_case_table_names = 1
> >>>
> >>> [3] SQL Server 2005 Expression config: collation -
> >> SQL_Latin1_general_CP1_CS_AS
> >>>
> >>> Andrus
> >>
> >>
>
>
Re: 3.1-final test scoresheet
Posted by Andrus Adamchik <an...@objectstyle.org>.
Done.
Once I was a big fan of terse non-redundant APIs. Not anymore :) Now that we are moving in the direction of richer user-facing APIs, builders, etc, so this only makes sense to add this method back.
Andrus
On Sep 5, 2014, at 4:16 PM, Michael Gentry <mg...@masslight.net> wrote:
> I seem to recall a discussion on that particular method years ago, but
> don't remember the details (I'd have to go back and find it).
>
> I'm fine with having deleteObject() just turn around and call
> deleteObjects() because it makes the calling code read better, even at the
> "expense" of cluttering up the API (although this isn't much, really).
>
> mrg
>
>
>
> On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> One possible last minute change is un-deprecating
>> ObjectContext.deleteObject(..). It can easily coexist with 'deleteObjects',
>> and getting rid of it was not the best idea on my part.
>>
>> Andrus
>>
>> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> In preparation to the 3.1-final vote, I ran the same set of tests as we
>> did for RC1. All tests are on Java 1.6 unless specified otherwise. You can
>> compare it with the previous results at
>> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything is
>> the same, so the latest 3.1 changes didn’t break anything obvious. There’s
>> one less test failure on Oracle, which is related to my improved Oracle
>> setup, rather than anything in Cayenne. Feel free to replicate the results
>> in your own environment.
>>>
>>> rat: PASSED
>>> hsql: PASSED
>>> h2: PASSED
>>> derby: PASSED
>>> derby/Java7: PASSED
>>> mysql 5.0: [1] PASSED
>>> mysql 5.6: [2] PASSED
>>> sqlserver [3] PASSED
>>> postgresql: Failures: 1
>> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> oracle 11: Failed tests:
>>> testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>> testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
>>>
>>> Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
>>>
>>> [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
>>>
>>> [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
>> lower_case_table_names = 1
>>>
>>> [3] SQL Server 2005 Expression config: collation -
>> SQL_Latin1_general_CP1_CS_AS
>>>
>>> Andrus
>>
>>
Re: 3.1-final test scoresheet
Posted by Michael Gentry <mg...@masslight.net>.
I seem to recall a discussion on that particular method years ago, but
don't remember the details (I'd have to go back and find it).
I'm fine with having deleteObject() just turn around and call
deleteObjects() because it makes the calling code read better, even at the
"expense" of cluttering up the API (although this isn't much, really).
mrg
On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> One possible last minute change is un-deprecating
> ObjectContext.deleteObject(..). It can easily coexist with 'deleteObjects',
> and getting rid of it was not the best idea on my part.
>
> Andrus
>
> On Aug 30, 2014, at 9:28 PM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > In preparation to the 3.1-final vote, I ran the same set of tests as we
> did for RC1. All tests are on Java 1.6 unless specified otherwise. You can
> compare it with the previous results at
> http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything is
> the same, so the latest 3.1 changes didn’t break anything obvious. There’s
> one less test failure on Oracle, which is related to my improved Oracle
> setup, rather than anything in Cayenne. Feel free to replicate the results
> in your own environment.
> >
> > rat: PASSED
> > hsql: PASSED
> > h2: PASSED
> > derby: PASSED
> > derby/Java7: PASSED
> > mysql 5.0: [1] PASSED
> > mysql 5.6: [2] PASSED
> > sqlserver [3] PASSED
> > postgresql: Failures: 1
> testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
> > oracle 11: Failed tests:
> > testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> > testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)
> >
> > Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0
> >
> > [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M
> >
> > [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
> lower_case_table_names = 1
> >
> > [3] SQL Server 2005 Expression config: collation -
> SQL_Latin1_general_CP1_CS_AS
> >
> > Andrus
>
>