This one fixed too. Waiting for the next one :)
On Fri, May 26, 2017 at 4:03 PM, Nikita Timofeev
<ntimof...@objectstyle.com> wrote:
> Yes, that's right :) I see this now in my test too, code path that I
> don't like (and that is hard to step on) bites again.
>
> On Fri, May 26, 2017 at 3:53 PM, Hugi Thordarson <h...@karlmenn.is> wrote:
>> That's always fun :). BarCode.CODE is a LONGVARCHAR mapped to a TEXT-column
>> in a MySQL db.
>>
>> - hugi
>>
>>
>>> On 26 May 2017, at 12:48, Nikita Timofeev <ntimof...@objectstyle.com> wrote:
>>>
>>> Yes, fix definitely affected this query, but seems that it's not broke
>>> something, but rather revealed some other hidden bug.
>>> What is the type of DbAttribute mapped on BarCode.CODE property?
>>>
>>> On Fri, May 26, 2017 at 3:37 PM, Hugi Thordarson <h...@karlmenn.is> wrote:
>>>> Is it possible the fix broke something else? I'm now getting exceptions
>>>> for queries that worked this morning. I only see it happening in queries
>>>> where i'm traversing to-many relationships in the where-part of the query
>>>> though. This method:
>>>>
>>>> public String number() {
>>>> return ObjectSelect
>>>> .query( BarCode.class )
>>>> .column( BarCode.CODE )
>>>> .where( BarCode.BAR_CODE_SKUS.dot( BarCodeSku.SKU
>>>> ).eq( this ) )
>>>> .selectFirst( getObjectContext() );
>>>> }
>>>>
>>>> (BarCode.CODE is a string)
>>>>
>>>> Now causes this error:
>>>>
>>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>>> org.apache.cayenne.DataRow
>>>> at
>>>> org.apache.cayenne.access.jdbc.DistinctResultIterator.checkNextUniqueRow(DistinctResultIterator.java:147)
>>>> at
>>>> org.apache.cayenne.access.jdbc.DistinctResultIterator.checkNextRow(DistinctResultIterator.java:136)
>>>> at
>>>> org.apache.cayenne.access.jdbc.DistinctResultIterator.<init>(DistinctResultIterator.java:74)
>>>> at
>>>> org.apache.cayenne.access.jdbc.SelectAction.forSuppressedDistinct(SelectAction.java:236)
>>>> at
>>>> org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:121)
>>>> at
>>>> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:97)
>>>> at
>>>> org.apache.cayenne.access.DataNode.performQueries(DataNode.java:293)
>>>> at
>>>> org.apache.cayenne.access.DataDomainQueryAction.runQuery(DataDomainQueryAction.java:471)
>>>> at
>>>> org.apache.cayenne.access.DataDomainQueryAction.access$000(DataDomainQueryAction.java:72)
>>>> at
>>>> org.apache.cayenne.access.DataDomainQueryAction$2.perform(DataDomainQueryAction.java:446)
>>>> at
>>>> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:87)
>>>> at
>>>> org.apache.cayenne.tx.DefaultTransactionManager.performInLocalTransaction(DefaultTransactionManager.java:59)
>>>> at
>>>> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:52)
>>>> at
>>>> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:40)
>>>> at
>>>> org.apache.cayenne.access.DataDomainQueryAction.runQueryInTransaction(DataDomainQueryAction.java:443)
>>>> at
>>>> org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:122)
>>>> at
>>>> org.apache.cayenne.access.DataDomain.onQueryNoFilters(DataDomain.java:564)
>>>> at
>>>> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery(DataDomain.java:748)
>>>> at
>>>> org.apache.cayenne.commitlog.CommitLogFilter.onQuery(CommitLogFilter.java:61)
>>>> at
>>>> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery(DataDomain.java:748)
>>>> at
>>>> org.apache.cayenne.tx.TransactionFilter.onQuery(TransactionFilter.java:49)
>>>> at
>>>> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery(DataDomain.java:748)
>>>> at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:556)
>>>> at
>>>> org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:382)
>>>> at
>>>> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache(ObjectContextQueryAction.java:107)
>>>> at
>>>> org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:94)
>>>> at
>>>> org.apache.cayenne.access.DataContext.onQuery(DataContext.java:965)
>>>> at
>>>> org.apache.cayenne.access.DataContext.performQuery(DataContext.java:954)
>>>> at org.apache.cayenne.BaseContext.select(BaseContext.java:307)
>>>> at org.apache.cayenne.BaseContext.selectFirst(BaseContext.java:331)
>>>> at
>>>> org.apache.cayenne.query.ColumnSelect.selectFirst(ColumnSelect.java:660)
>>>> at strimillinn.core.model.Sku.number(Sku.java:54)
>>>>
>>>> Cheers,
>>>> - hugi
>>>>
>>>>
>>>>
>>>>> On 26 May 2017, at 11:56, Nikita Timofeev <ntimof...@objectstyle.com>
>>>>> wrote:
>>>>>
>>>>> Hi again,
>>>>>
>>>>> I've pushed fix for this issue.
>>>>> https://github.com/apache/cayenne/commit/eac1f31073045fec6eafef3f3fd6cb05f0201994
>>>>>
>>>>> On Wed, May 24, 2017 at 7:03 PM, Hugi Thordarson <h...@karlmenn.is> wrote:
>>>>>> Thanks Nikita, at least I know I'm not doing anything wrong then :)
>>>>>>
>>>>>> - hugi
>>>>>>
>>>>>>
>>>>>>> On 24 May 2017, at 14:52, Nikita Timofeev <ntimof...@objectstyle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Hugi,
>>>>>>>
>>>>>>> Seems like custom types are broken in ColumnSelect, I see this bug in
>>>>>>> my test too.
>>>>>>>
>>>>>>> On Wed, May 24, 2017 at 5:34 PM, Hugi Thordarson <h...@karlmenn.is>
>>>>>>> wrote:
>>>>>>>> I'm using today's version of 4.0.M6-SNAPSHOT. Always living on the
>>>>>>>> edge :)
>>>>>>>>
>>>>>>>> - hugi
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 24 May 2017, at 14:31, Andrus Adamchik <and...@objectstyle.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Or .. if you already have cayenne-java8 in your app, and the problem
>>>>>>>>> is specific to just the column select query, you may also need to
>>>>>>>>> switch to M6. IIRC there were some issues in M5 with the behavior
>>>>>>>>> that you describe.
>>>>>>>>>
>>>>>>>>> Andrus
>>>>>>>>>
>>>>>>>>>> On May 24, 2017, at 5:28 PM, Andrus Adamchik
>>>>>>>>>> <and...@objectstyle.org> wrote:
>>>>>>>>>>
>>>>>>>>>> You need to add cayenne-java8 dependency.
>>>>>>>>>>
>>>>>>>>>> Unfortunately the fallback behavior (treat unknown class as
>>>>>>>>>> Serializable) is extremely confusing. Though I think we log some
>>>>>>>>>> warnings before doing that.
>>>>>>>>>>
>>>>>>>>>> ANdrus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On May 24, 2017, at 5:20 PM, Hugi Thordarson <h...@karlmenn.is>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>> if I try to fetch Java 8 date objects using ColumnSelect, the
>>>>>>>>>>> values get returned as byte arrays instead of actual objects.
>>>>>>>>>>> Example:
>>>>>>>>>>>
>>>>>>>>>>> LocalDateTime creationDate = ObjectSelect
>>>>>>>>>>> .query( User.class )
>>>>>>>>>>> .column( User.CREATION_DATE )
>>>>>>>>>>> .selectFirst( Jambalaya.newContext() );
>>>>>>>>>>>
>>>>>>>>>>> User.creationDate() is a LocalDateTime—but the fetch will fail
>>>>>>>>>>> since the returned value is a byte array.
>>>>>>>>>>>
>>>>>>>>>>> Bug?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> - hugi
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Nikita Timofeev
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>
>
>
>
> --
> Best regards,
> Nikita Timofeev
--
Best regards,
Nikita Timofeev
