[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515509#comment-16515509
 ] 

ASF GitHub Bot commented on IGNITE-6528:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3923


> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.6
>
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501522#comment-16501522
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~vozerov] 
1) I should reword this probably. Query Entities take type names as strings. 
It's possible to have a typo there or wrong package (or absense thereof)
2) Consistently - either present always, or absent always!

Note that it is possible to configure indexedTypes correctly and still fail to 
put correct BinaryObject to cache (by creating binaryObjectBuilder of wrong 
type)
And it's possible to configure queryEntities on wrong type name that never 
corresponds to class.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.6
>
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495106#comment-16495106
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~vozerov] please review the patch.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480774#comment-16480774
 ] 

Taras Ledkov commented on IGNITE-6528:
--

[~ilyak], the patch is OK with me.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480736#comment-16480736
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] I've updated it again, please look. Sigh.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479445#comment-16479445
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] please review amended fix.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477511#comment-16477511
 ] 

Taras Ledkov commented on IGNITE-6528:
--

[~ilyak], I guess one warning must be printed for one  
pair.
Looks like the current patch prints only one warning for a cache.
i.e. The warning for the next operation with other type won't be logged.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474164#comment-16474164
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] I have removed extra iteration and now avoid issuing 
warning more than once. Please take a look at changes.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464161#comment-16464161
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] I have removed unused import and fixed message format.

Yes iteration over all types is wasteful. We could do hard throttling to make 
sure that we only ever report warning once per cache, but this will require 
adding a transient boolean flag to some unrelated class to carry this info 
around.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463506#comment-16463506
 ] 

Taras Ledkov commented on IGNITE-6528:
--

[~ilyak], the patch looks good.
My comments:
1. Please remove unused import
2. Please change log message format at the {{GridQueryProcessor#store}} 
according with Coding Guidelines *String Output*.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454226#comment-16454226
 ] 

Ilya Kasnacheev commented on IGNITE-6528:
-

[~tledkov-gridgain] please review proposed change.

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6528) Warning if no table for BinaryObject

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454223#comment-16454223
 ] 

ASF GitHub Bot commented on IGNITE-6528:


GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/3923

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6528

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3923.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3923


commit 925ad48468f82053005031f3b5b5eca85323b019
Author: Ilya Kasnacheev 
Date:   2018-04-26T13:40:27Z

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.




> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)