Daily Log for #alfresco IRC Channel

Alfresco discussion and collaboration. Stick around a few hours after asking a question.

Official support for Enterprise subscribers: support.alfresco.com.

Joining the Channel:

Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.

More information about the channel is in the wiki.

Getting Help

More help is available in this list of resources.

Daily Log for #alfresco

2019-02-27 09:29:33 GMT <redcomm> Hi!

2019-02-27 09:30:10 GMT <redcomm> Maybe you can help me to find the right path to follow ..

2019-02-27 09:30:55 GMT <redcomm> We are working on Alfresco/ADF/ACA addon to link content with "external sources" (using REST)

2019-02-27 09:32:14 GMT <redcomm> after investigating the alternatives to store these kind of info in the model (multivalue/multicolumn) we decide to use JSON structure to store the information on a property

2019-02-27 09:33:06 GMT <redcomm> limitation : obviously we can't use facets over this property as is (JSON)

2019-02-27 09:34:51 GMT <redcomm> Question : Is there any documentation about search-services to create some kind of custom tokenizer to extract only part of the JSON body and index ONLY this part?, so we can send Solr "named_property + parsed value"

2019-02-27 09:37:14 GMT <redcomm> I knew you can do it in previous version but is not clear which parts will be delegated to new alfresco-search-services

2019-02-27 11:56:50 GMT <AFaust> redcomm: I am afraid the Alfresco documentation does not contain anything relating to custom tokenisers as Alfresco likely does not intend customers / users to modify their Search Services product in such a way (and still be supported).

2019-02-27 11:57:37 GMT <AFaust> But since Search Services is a "regular" SOLR-based system, you can of course check their general documentation and try to apply any of the common approaches to the Alfresco-specific default config.

2019-02-27 11:58:15 GMT <redcomm> Ok, thanks Axel!

2019-02-27 11:59:04 GMT <redcomm> I'm not able to find the "breaking changes" about datatype analyzers from 4.X to 5.X

2019-02-27 11:59:12 GMT <AFaust> Generally though, I would typically advise against storing JSON as property values. If that truly is the only way you can represent your information in Alfresco adequately, I would pose the question if you would not be better served by picking a different storage / management system.

2019-02-27 12:00:54 GMT <redcomm> I'll check it in deep or try to find another alternative (we where thinking about associations with sys:base object but looks like is worst in the search context)

2019-02-27 12:01:35 GMT <redcomm> I understand your advise ;)

2019-02-27 12:02:33 GMT <redcomm> Do you have any example about "different storage / management system" ??

2019-02-27 12:03:40 GMT <troffasky> i believe postgres has a native JSON type

2019-02-27 12:04:45 GMT <redcomm> there is a lot of limitations when you think about to store this kind of info outside Alfresco (concerned to security mainly)

2019-02-27 12:06:28 GMT <redcomm> but for search purposes too

2019-02-27 12:16:00 GMT <redcomm> other "crazy" alternative I was thinking : create a sys:base type to store the external info entity as tipical props (think about customer : first name, last name, birth), once has been assigned to a content. So you are querying the external system and storing plus associating the entity with the content inside Alfresco (better to avoid info duplication and for synchro purposes) .. the limitation : looks like is really complex t

2019-02-27 12:17:01 GMT <redcomm> I'm at bainstorm phase so there are no limits about crazy ideas :P

2019-02-27 12:20:51 GMT <redcomm> by the way .. I wrote a forum post about .. the final decission will be posted there -> https://community.alfresco.com/message/842078-alfresco-56-custom-json-tokenizerparser

2019-02-27 12:20:52 GMT <alfbot> Title:Alfresco 5/6 Custom JSON Tokenizer/Parser | Alfresco Community (at community.alfresco.com)

2019-02-27 12:36:06 GMT <AFaust> If your JSON is simple enough that (the relevant) attributes can be mapped 1:1 to properties, I personally would go that route. The JSON could still be stored "as-is" as a d:content property, and a metadata extractor could be developed / configured to extract the relevant attributes as property values.

2019-02-27 12:37:09 GMT <AFaust> But since you said you already looked at properties, multi-valued etc. I am skeptical as to how that should now map well when you already excluded that option to begin with

2019-02-27 12:53:22 GMT <redcomm> For that scenario the problem arrives when your JSON has more than one entry (more than one customer/provider/project, for example) .. and the multivalued fields is not an option at all (very limited to keep the entity related props when dealing with null values)

2019-02-27 12:58:48 GMT <redcomm> for example : "an user selects two customer but with null in birth field for one of them" .. if you don't use some kind of mask for null values you are "breaking" the multivalued fields array structure

2019-02-27 13:00:35 GMT <redcomm> and I don't like this "masking null" approach

2019-02-27 13:01:23 GMT <redcomm> but at the end maybe it is the best native "out-of-the-box" option

End of Daily Log

The other logs are at http://esplins.org/hash_alfresco