Datastore Conversion
Jamroom Developers
@michael
Perfect! This is clearly the way to go. Thanks much Michael.
Forum Activity for @tig
Datastore Conversion
Jamroom Developers
@michael
We need to do an algorithmic conversion. The Batch editor appears to be designed for making manual changes.
Recently Paul and Brian made an update to jrComment which introduced concatenated keys for performance. I am looking to follow their lead and use the same method (although in my case I am not doing this to introduce concatenated keys). So I would have code that would inspect the comments and make the selective adjustments as needed.
I presume they did a db backup, used some mechanism to invoke their code to create the new concatenated keys and possibly some mechanism to verify integrity. I could roll my own method but I figured it best to do what JR does.
updated by @tig: 12/27/17 10:50:11AM
Datastore Conversion
Jamroom Developers
What is the recommended method to make bulk modifications to a data store?
In our case, we need to (occasionally) change the value of one property (a count) and in some cases add a new (derived) property. This will be done on the jrComment datastore so in our case the conversion will process an enormous number of items.
Logically the conversion algorithm will work on the comments for one discussion, group discussion or blog at a time. Thus it could take place when either of these aggregates are accessed. That is, it could be on-demand rather than converting the entire store all at once.
Bottom line, just looking for the JR prescribed method for datastore conversions.
updated by @tig: 03/30/18 04:44:28AM
Reordering Threaded Comments
Jamroom Developers
@brian
Great to know that! It is one thing to have a mechanism to effect this kind of a change, but it is another to have one that is recognized and supported by JR architecture going forward. Thanks for increasing my comfort because this is core to an important new feature for NT.
Reordering Threaded Comments
Jamroom Developers
@michael
Makes sense. The module I used was set at a priority lower than jrComment for historical reasons so I figured I would be okay in terms of the registration order.
Reordering Threaded Comments
Jamroom Developers
@michael
My solution pretty much did the same thing - my code was placed within my existing ntComment override module:
My module's init starts with this:
ntComment_unregister_event_listener('jrCore', 'db_search_items', 'jrComment_db_search_items_listener');
... to disable the jrComment listener. I then register my replacement listener normally.
The unregister function looks remarkably like your code:
function ntComment_unregister_event_listener($module, $event, $function)
{
$ename = "{$module}_{$event}";
if (($key = array_search($function, $GLOBALS['__JR_FLAGS']['jrcore_event_listeners'][$ename])) !== false)
{
unset($GLOBALS['__JR_FLAGS']['jrcore_event_listeners'][$ename][$key]);
}
return true;
}
Given we used the same approach this is a good solution by definition, right?
A good pattern to have in inventory. Thanks.
Reordering Threaded Comments
Jamroom Developers
Quote: Your goal is to have a way for that listener NOT to fire (as I understand it).
@michael
Yes. My goal is actually to override a single function but sans that ability, the next best thing is to prevent the jrComment db search listener from firing and totally replace it with my own listener.
I understand that you are brainstorming and that you are not suggesting this as the Jamroom recommended approach. But if you guys ever pursue anything along these lines, one nice function would be an unregister (i.e. jrCore_unregister_event_listener). This function would only be allowed for modules that are defined as extensions so there would be a need for another function to link an extension module to its parent (a subclass relationship). If that were in place then JR would have a controlled mechanism to fully override event handlers and thus gain a bit of helpful polymorphism. Another approach (more consistent with the JR style) would be for any function defined in an extension (the subclass) to automatically fully override similarly named functions up the lineage. That would be outstanding. If that were in place today, I would simply create my own ntComment_thread_comment function (in ntComment) to fully override the jrComment_thread_comment in jrComment. Clean and future-proof.
Back to reality ...
When I have a chance to experiment, I will first, in effect, build a simple unregister function. I will try to locate it within the extension module, but I suspect my first roadblock will be timing - ensuring the unregister is placed at the right time so that it accomplishes the desired result. And, indeed, there may be no way to do this reliably.
updated by @tig: 12/23/17 05:11:11PM
Reordering Threaded Comments
Jamroom Developers
@michael
Interesting. If this could be done safely then we would have a general purpose mechanism for overriding listeners. This could significantly increase the flexibility of the platform IMO.
Immediately, from your suggestion, this is the function for me to investigate:
function jrCore_register_event_listener($module, $event, $function)
{
// We can register 1 of 3 events:
// a specific event from a specific module - i.e. 'jrUser','get_info_by_id'
// all events from a specific module - i.e. 'jrUser','all_events'
// all events for the whole system - i.e. 'jrCore','all_events'
if (!isset($GLOBALS['__JR_FLAGS']['jrcore_event_listeners'])) {
$GLOBALS['__JR_FLAGS']['jrcore_event_listeners'] = array();
}
$ename = "{$module}_{$event}";
if (!isset($GLOBALS['__JR_FLAGS']['jrcore_event_listeners'][$ename])) {
$GLOBALS['__JR_FLAGS']['jrcore_event_listeners'][$ename] = array();
}
$GLOBALS['__JR_FLAGS']['jrcore_event_listeners'][$ename][] = $function;
return true;
}
I could construct a function that simply removes a registered event listener from
$GLOBALS['__JR_FLAGS']['jrcore_event_listeners']Seems a bit pathological to me, but considering the options this looks to be a reasonable course to at least investigate. Thanks for the tip!
Reordering Threaded Comments
Jamroom Developers
Quote: your question is how to change jrComment_thread_comments to that structure?
@michael
I know (algorithmically) how to effect the hybrid tree reordering (easy enough) so that is not my question. My question was how I could best simulate an override of this single function in the jrComment module.
Nothing else in jrComment would be affected so overriding the entire module and changing references in the balance of the code is not an appealing notion.
Regardless, you have answered my question so thanks for that. I will look for something akin to overriding the
jrComment_db_search_items_listener
jrComment_thread_comment
Thanks, as always, for the advice Michael.
Reordering Threaded Comments
Jamroom Developers
We plan to provide a hybrid comment structure - where nodes at level 'n' and beyond are simply treated as a linear chronologically ordered list. This provides the benefit of the threaded comment structure as the major organization and then (when too deep in the hierarchy to be coherent) renders simply as a list of chronologically ordered comments. The attached png shows the results we are after (our actual n will be one less). We understand (and currently use) the flattened hierarchic presentation JR uses when the max level is reached. Our challenge is with the actual data structure and -in consequence- the true hierarchic numbers of the nodes (e.g. 3.1.7.4).
That established, to pull this off we would ideally replace the
jrComment_thread_comments
Since that is not possible, any ideas on the next best (in terms of future proofing) approach to get as close to the above ideal as possible within the JR architecture?
updated by @tig: 03/27/18 08:18:37PM
