Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.


If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping


Answers may be delayed for posts that do not include sufficient information.

Replication not picking up ca_object_labels entries

edited January 18 in Troubleshooting

We're having some issues with the replication process not picking up ca_object_labels. It works fine if the initial replication happens when the object is accessible, however if the object is initially in a Not Accessible state the object labels are not replicated once the object state is changed to Accessible and the replication is rerun. In the replication log the following message is shown. The f44 GUID is related to the ca_object entry and the c9e GUID is associated with the ca_object_labels. It is skipping it because of a comparison on line 369 in app/lib/Sync/Replicator.php, but I'm not sure what your logic is trying to do there.

From replication.log:

Thu 2019-01-17 09:20:17 DEBUG: SKIP dependent f44e1dbd-92f5-4453-aa5a-95bf952786e1 because log entry matches guid: Array
(   
    [i] => 20888
    [log_id] => 20888 
    [log_datetime] => 1526755381
    [user_id] => 1
    [changetype] => I
    [logged_table_num] => 50
    [logged_row_id] => 5
    [rolledback] => 0
    [snapshot] => Array
        (   
            [label_id] => 5
            [object_id] => 5
            [locale_id] => 3
            [name] => Chair
            [name_sort] => Chair
            [is_preferred] => 1 
            [object_id_guid] => f44e1dbd-92f5-4453-aa5a-95bf952786e1
            [object_guid] => f44e1dbd-92f5-4453-aa5a-95bf952786e1
            [locale_id_guid] => f69175b2-192d-4b72-a4fa-26bfbe3179f4
            [locale_code] => en_US
        )
    
    [guid] => c9e8946d-2603-4b00-8d23-3b2a2a9e3075
    [subjects] => Array
        (   
            [0] => Array
                (   
                    [log_id] => 20888
                    [subject_table_num] => 57
                    [subject_row_id] => 5
                    [guid] => f44e1dbd-92f5-4453-aa5a-95bf952786e1
                )
        
        )

)

Comments

  • It should pick them up retroactively once the state is changed to accessible. When it hits the log change where the accessibility change is made is will pull all log entries for the object going back to the beginning and replay them. Post the line you're talking about. There is no Replication.php file. Thanks.

  • I meant Replicator.php.
    Section in app/lib/Sync/Replicator.php is:

                                                        if(is_array($va_missing_entry['snapshot'])) {
                                                            $va_dependent_guids = array_unique(array_merge($va_dependent_guids, array_values(array_filter($va_missing_entry['snapshot'], function($v, $k) use ($va_missing_entry, $x, $vs_missing_guid) { 
                                                                if ($v == $vs_missing_guid) { 
                                                                    $x->log(_t("SKIP dependent %1 because log entry matches guid: %3", $v, $matches[1], print_R($va_missing_entry, true)), Zend_Log::DEBUG);
                                                                    return false; 
                                                                }
    
  • Ok this is from Replicator.php ... the skipping going on here is referring to extraction of dependencies. It's just logging that it's not considering the object itself to be a dependency for itself. This is normal. The label was pulled because it's related to the object being synced.

    Look later in the log to hopefully find clues as to why the label isn't getting pulled. It may well be that you have restrictions on the target system that are causing issues. For example, perhaps your target has restrictions on duplicate labels. One each source system labels aren't duped, but when you merge them they are. In that case the target will reject the label. This is just a guess. Something is going on obviously, but this log entry isn't it.

  • This is only happening when the initial state is Not Active. If I duplicate the object in the source system, set the label of the duplicated object to be the same (Chair in this case) and rerun the replication, the duplicated object's label is replicated properly.

    The above SKIP message happens twice in the log file, and the only other time the table number 50 comes up in the log is part of this log message:

    Thu 2019-01-17 09:20:18 DEBUG: GOT 26 entries for f44e1dbd-92f5-4453-aa5a-95bf952786e1
    Thu 2019-01-17 09:20:18 DEBUG: Array
    (
  • And note that this happens for every single object that we change from Not Accessible to Accessible.

  • edited February 8

    Still trying to track this down. One thing I noticed is that in the ca_change_log, the unit_id is null for the log pertaining to the insert of the ca_object_label. The rest of the unit_ids for the insert of the object (which was done by an insert via the API) have the same unit_id of 814661d648e306e160eaea79f8e53cf4. Is there a reason the there is no unit_id for the ca_object_label insert? It doesn't seem to be the issue though because it doesn't fix the problem if I set it to match the others. I don't have any restrictions in the replication.conf file pertaining to duplicate labels.

  • The other strange thing I'm seeing in the log is the following message:
    Fri 2019-02-08 08:55:18 DEBUG: Skipped 26843 because dependency f69175b2-192d-4b72-a4fa-26bfbe3179f4 is not available
    That GUID is associated with the locale_id en_US. Is there any chance that could be the issue? The strange thing is that if I duplicate an object that is initially Not Accessible, and then change both the original object and the duplicated object to Accessible the duplicated object labels replicate properly, but the original one does not.

  • Locale might be the issue. I'm using this sort of replication on about half a dozen systems where records are changing every day and replication is run nightly. None have exhibited the issues you've surfaced (and some of them have been running for a couple of years), but they're all using en_US as their only locale. No mixed locales in other words.

    Are you still running this on the same BC server I had access to once upon a time? Maybe I can take a look?

  • I think it's a different set of servers now. I'll send you an email with the name of the server just in cause you still have access.

  • It looks like it's treating the ca_locale associated with the label as a dependency. I hacked the Sync/Replicator.php to not include locale_id_guid dependencies in the $va_dependent_guids. This probably isn't the right place to do it, however it did resolve the problem we're encountering. From Replicator.php (starting line 392 in current develop branch):

                                                            if(preg_match("!([A-Za-z0-9_]+)_guid$!", $k, $matches)) {
                                                                 if ($matches[1] === "locale_id") {return false;} // <<< FIXES CURRENT ISSUE
                                                                if(
                                                                    is_array(Datamodel::getFieldInfo($va_missing_entry['logged_table_num'], $matches[1]))
                                                                    ||
                                                                    is_array(Datamodel::getFieldInfo($va_missing_entry['logged_table_num'], $matches[1].'_id'))
                                                                ) { 
                                                                    return true; 
                                                                }
                                                            }
    
  • Ok that makes sense. You don't have en_US configured in locales?

  • It is configured - not sure why it isn't picking it up. Once again, if the record is duplicated with the GUI, the strange thing is that it the duplicated version of the record will replicate without changes to the codebase, however the original will not. en_US is set as the locale in both the setup.app and exists in ca_locales table with dont_use_for_cataloguing set to 0.

  • Ok but you're also using en_CA as a working locale, no? At least we know it's locale related now. That makes sense, as we don't have any working systems mixing locales at the moment. I can set up a test environment to work on this.

  • I changed it back to en_US in setup.php. en_US always had dont_use_for_cataloguing set to 0 in the ca_locales table. The locale in the ca_object_labels, and in the ca_change_log_snapshots.snapshot are both set to en_US for all records. When doing testing and tracking down the issue I compared the ca_change_log_snapshots.snapshot and ca_object_labels between the original and duplicated records and they are exactly the same wrt their locales.

Sign In or Register to comment.