[BUGS]Multi-reference & Hooks not working

Ask the community
,
1

I’m currently working with hooks for a database with multi-reference field.

First bug: editor’s data manager does not trigger hook “afterUpdate”

When adding or removing a reference in a multi-reference field from the editor data manager the hook is not trigger.

  1. Are you aware of that? If so why is it not stated in the documentation ?

  2. Is that something you can fix? if so when?

Second BUG: multi-reference properties are absent from item

When an item with a multi-reference field is updated, the “afterUpdate” callback received an item that’s missing the property for the multi-reference field.

EXAMPLE

This means we cannot keep our data sync. We should at least received an array of Ids!

  1. Are you aware of this bug? It should be clearly stated in the documentation bout hooks

  2. Is that something you can fix? If so when?

@sheyla

2

editor’s data manager does not trigger hook “afterUpdate”

How are you using the hook? are you using something like ( return item;) ? Have you used other methods to determine if the hook is actually not firing or the code inside the hook is not working?

In general: Hooks are very inconsistent from my experience. Its better to do the following instead of using return item ;

import wixData from 'wix-data';

let options = {
 "suppressAuth": true,
 "suppressHooks": true
};

export function databaseOne_afterUpdate(item, context) {
    item.title = 'Not Updated';
    wixData.update('databaseOne', item, options); //instead of return item; OR return Promise.resolve(item)
}

(Following this thread for any update)

3

@plomteuxquentin Yes, I have the same experience as Shan just stated. Better to do it from code. On a larger note: are you sure you want to use Wix´s implementation of n-m relationships using multi-refs? It´s very non-standard, we have no idea how this performs under large loads and we do not know if it is anywhere near stable. I had the same problem and I stayed clear of using multi-refs and just solved it the old-fashioned way, using a third table/collection.

4

@giri-zano That really sad, to see it like that. I want to put a bit of trust on Wix. If what you say is true, it’s really a shame that we can’t rely on the tools provided.

But yeah I’m going to do that the traditional way I guess. Thank for the tip

@Shan my issue is not with updating the item but rather having the whole item so I can do operation on other collection: I need to keep 2 database sync (several masters, one salve) So if anything changes on any of the masters I would like to create/update a record in the slave database. My problem is that the initial(master) record is lacking information for multi-reference field those I can’t update the slave properly

also I never had issue doing:

export function databaseOne_afterUpdate(item, context) {
    item.title = 'new ' + item.title;
    return item;
}
5

Re: the second bug, still having it. The multi-reference items do show up in the _beforeUpdate hook still. I have to do all my interactions there.

6

Good to know Christopher,

but what if the update fails? That far from an ideal solution

Can someone from wix Have a look?

7

@plomteuxquentin I am having the same experiences/problems with MultiRef fields.

I really wanted to use MultiRef fields for a few reasons:

  1. I want to enforce the setting of only known values in a field. Wix does not have a database collection type like enum. So the only way* you can guarantee that a field has legal values is to use a reference field.

  2. I wanted to create UI elements such as Checkbox Groups containing all the possible values of a column, the only easy way to do this by reading all the values in the reference table.**

  • You could do elaborate validation checking, but this is a pain in the butt.

** Without using Reference Fields, I don’t know how you’d do this. Does Wix even have an aggregate query like SQL DISTINCT? If not, you’d have to hardcode all the known values, which sucks if you ever add or change a value.

SingleRefs work. MultiRefs are horribly…HORRIBLY broken.

  1. INVISIBLE TO QUERY/GET: SingleRef IDs are returned when you query/get the main table. MultiRef IDs are not. This means they are completely invisible. Of course, you can always do a queryReferenced to get the MultiRef field data, but…oh man…just try doing that inside a repeater for every single row in the repeater. Can you say PERFORMANCE NIGHTMARE? It is impractical to do even one queryReferenced on rows and rows of data. It is downright awful if you need to look up the values of more than one MultiRef (and I have 4!). Also, if you try to do this using hooks, it doesn’t work. I tried to do this on a Dynamic page, and it did strange things, and sometimes spun forever. I’m guessing it’s just recursively doing queries or something, even though you’re doing a queryReferenced, not a query. I would hope that queryReferenced wouldn’t also trigger the query hook, but it looks like it does. I didn’t do a lot of debugging into this. I just abandoned it.

  2. INVISIBLE TO DB MODIFICATION: If you set a SingleRef field using the Content Manager or by using wixData directly in your code, the update hooks are triggered. NO HOOKS are triggered when changing a MultiRef value. This means MultiRef changes are completely invisible. You cannot, in any way, detect when a MultiRef field is changed. Ironically, though, changing a MultiRef DOES update the updated timestamp in the main and reference tables. But there’s no hook I can use to detect when the update timestamp has changed. Again, MultiRefs are invisible to all hooks, and you cannot perform any logic if a MultiRef is updated through the Content Manager. Of course, if you are controlling all updates with your own code and not with the Content Manager, you can do anything you want. But the moment anyone uses the Content Manager instead of the UI you provided to update something, you’re screwed. Whatever code you needed to run when something updates WILL NOT RUN. And now your tables are out of sync/incorrect.

Because it is basically impossible to get MultiRef fields in a query for use in a repeater, I thought I would just create an index table, where I flatten all the multiref data into Objects, and then create the repeater against the index table instead of the main table with all the insane queryReferences that don’t really work anyway. That’s when I ran into problem #2. How to create/maintain that index table?

Short answer: YOU CAN’T.

Long answer: I think I will need to either run a cron job that periodically reindexes all rows that have updated timestamps newer than the last index run. Another option might be to block all of my website admins from actually making any changes to the database using the Content Manager, and instead create UIs with forms that allow me to trigger the reindex myself.

CONCLUSION:
MultiRefs are really POORLY thought out by whoever envisioned these at Wix. It’s like…Hey! Great Idea! But you can’t actually use them for much. You can’t query them. You can’t detect when they change. I guess they’re amazing if you need A COMPLETELY INVISIBLE FIELD.

I will concede that there are two things that do work really well.

  1. filters on a list page. You can actually apply filters to datasets for MultiRef columns and it works great. This makes building complex Search UIs a lot easier than if you had to build filters on free text fields.

  2. filter on a single item page. The dataset on that page is restricted to a single collection ID. Then you can create other datasets that are filtered by the main dataset’s ID. That works nicely.

The worst part about this is that MultiRefs could overcome all of these shortcomings with just TWO changes:

  1. Give us a hook that we can use to detect when a MultiRef column changes, or just allow the update hook to work. It works for SingleRefs…just make it work for MultiRefs!

  2. Return just the MultiRef IDs on a normal query, without having to do a queryReferenced. Again. It works this way for SingleRefs…just make it work for MultiRefs! If you want a deep copy, you should still do a queryReferenced. But I think that even just having the IDs, or just the IDs and Title would be great. Possibly even, you could allow the caller to specify a subset of fields of our choosing, as long as they themselves aren’t Reference fields.

I’ve been around and around with various people in Wix support over this. Most of the time, they either don’t understand what I’m saying, or they just quote me the docs, which I’ve read, and which DO NOT OFFER ANY SOLUTION for this problem.

Wix engineers. Please make MultiRefs useful. They are so close!

Thank you