polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: Sorting out issues with Indexing SQL
Date Tue, 04 Apr 2017 09:26:36 GMT
On 4.4.2017 11:03, Niclas Hedhman wrote:
>> Indexing-SQL scans whole application structure on startup to detect all
> the visible and indexable entity composite types, and if the things changed
> there, it might cause problems.
> Oy!  Do you remember How/Where is that done? Because the EntityComposite
> type is added to the EntityDescriptor and must be done that way (or the
> Entity object with instanceof) and not be checking the Java interfaces.
> That could be the root of many problems.

It is "constructApplicationInfo" method in 
However, I am looking at it (via GitHub - still no Java IDE here), and 
it doesn't _seem_ to use direct type check - it uses EntityDescriptors 
You still might wanna make sure that it actually works as needed.

Unfortunately, I couldn't find the code which emits "unsupported 
property type" messages (no text-content-search in Github :( ), but 
putting a breakpoint in there might reveal something crucial.
I am very certain that I didn't get any of those when I got Indexing-SQL 
working back in the days.

> The other change is that identity is now a type and not String, and
> somewhere that might cause problems.
> Rewrite; Yeah, I have been considering this for a while. And perhaps build
> something by leveraging QueryDSL (http://www.querydsl.com/), or at least
> borrow internals for it. But I concluded that it was more work than fit
> into 3.0 plan. But I would be really happy to get to a situation where we
> have "ES backed indexer", which would help a lot going forward. The RDF
> implementation is also getting "old"...
> Cheers
> Niclas
> On Tue, Apr 4, 2017 at 3:15 PM, Stanislav Muhametsin <
> stanislav.muhametsin@zest.mail.kapsi.fi> wrote:
>> Hi!
>> Hmm yeah, it's been quite a while since I wrote that beast. :D I would do
>> a lot of things differently now, but I guess we are stuck with what we have
>> (until someone rewrites that).
>> There was a discussion in October 2016, and I am not sure if the issue
>> discussed then has been resolved, or maybe is (partially) the cause for
>> errors.
>> I will copy-paste my reply I wrote in October at the end of this mail.
>> Looking at that issue link ( https://issues.apache.org/jira
>> /browse/POLYGENE-222 ), there might be something in detection of entity
>> composite types - looks like "the first bad commit" was something about
>> entity composite types no longer needing to extend EntityComposite
>> interface?
>> Indexing-SQL scans whole application structure on startup to detect all
>> the visible and indexable entity composite types, and if the things changed
>> there, it might cause problems.
>> The other commits are more unfamiliar territory for me - looking at
>> attached test report, I think the most important information is the
>> standard output.
>> There is a bunch of "unsupported property type" messages - are
>> associations and manyassociations in Polygene just Property<..> these days?
>> That definetly will break things in Indexing-SQL.
>> It is a bit hard to follow for me since so many things have changed in
>> Polygene now (which is also a good thing - a sign of development!).
>> Here is the copy-paste from October.
>> It seems that the problem was Indexing-SQL not recognizing "Identity" type
>> as primitive (something like 'String' or 'Integer').
>> -------- BEGIN QUOTED MAIL --------
>> In "extensions/indexing-sql/src/main/java/org/apache/zest/index
>> /sql/support/skeletons/AbstractSQLStartup.java" file, there is
>> "initTypes" method.
>> You might want to add mapping for Identity.class in this._primitiveTypes
>> and jdbcTypes, and also most likely this._customizableTypes.
>> I say "might" want to, since I have really really vague memories on how
>> that worked, and I realized I don't have any PC right now with Java coding
>> environment set up.
>> The "appendColumnDefinitionsForProperty" method in the same file uses the
>> type mappings mentioned above to deduce what kind of column is to be
>> created for property, which might be the issue here.
>> Also, you probably want to modify the "/extensions/indexing-sql/src/
>> main/java/org/apache/zest/index/sql/support/common/QNameInfo.java" file,
>> so that the detection whether some Java type is primitive is updated to
>> include Identity.
>> It is done just before setting this._isFinalTypePrimitive.
>> Let us know if this is of any help to you.
>> -------- END QUOTED MAIL --------
>> On 03/04/2017 19:53, Paul Merlin wrote:
>>> Stan, Niclas,
>>> Indexing SQL has been broken for quite some time.
>>> See https://issues.apache.org/jira/browse/POLYGENE-222
>>> That issue contains the result of bisecting the history to identify when
>>> it broke. With the Docker based testing infra it is now very easy to
>>> reproduce.
>>> Stan, you wrote that beast :)
>>> Niclas, one commit of yours broke that beast :)
>>> Could you have a look?
>>> Thanks!
>>> /Paul

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message