Converting spider web to anchor bouy

[cwcrogan]

Hello all,

I'm trying to wrap my head around something and would love some input. I'm converting a solution from spider web to anchor buoy.

First, my previous setup involved a few tables where all the (base) TOs are connected to one another in somewhat of a mess and I have a number of layouts on those TOs. Part of this involves two tables - Addresses and Hydrants. Each address has hydrants related to it (between 2 and 5, but usually 3). These relationships will very rarely change (basically only when a hydrant is removed). Instead of a join table, I used a multi-value foreign key in addresses to relate to the hydrants. This is working perfectly both in the spider web and with a new TO for the anchor buoy, but I guess I would like reassurance that the multi-value foreign key is appropriate (as opposed to a join table or other).

Next, I had a script from the Addresses context that would grab the address info then jump to the related hydrants via GTRR and create an array of markers for a google map. Worked great with the spider web, using a layout for addresses and another for the map based on hydrants. But my learning taught me to only use layouts on anchors and my conversion to anchor buoy broke the script. I have now, in the anchor buoy setup, an Addresses anchor with a related Hydrant buoy for the Hydrant portal, and a layout for Addresses - works great. I also have a Hydrant anchor with a layout for Hydrants and a related Addresses buoy (separate from above).

The way I see it, to get the script to work again I can do one of two things (or perhaps more with insight). From the address context (and layout) I could grab the address ID, go to the Addresses buoy from Hydrants anchor, perform find for the address ID and then use GTRR to jump to the Hydrants anchor and create the map. OR, I could create a new Hydrant buoy from Hydrant anchor (self join using a global field to ID) and then, again from the address context, grab the multi-value hydrant foreign key, populate the global, and then GTRR back to Hydrant anchor from the Hydrant buoy. It took me days to complete, but I actually have it working using the second method.

Is my solution appropriate? Is there another (better) way of handling this? I greatly appreciate any input.

[comment]

4 hours ago, cwcrogan said:

I would like reassurance that the multi-value foreign key is appropriate (as opposed to a join table

A multi-value key can be used instead of a join table provided that:

1. The join itself has no properties; and
2. You do not need to produce a report of hydrants by address (or vice versa).

 

4 hours ago, cwcrogan said:

my learning taught me to only use layouts on anchors and my conversion to anchor buoy broke the script.

When you GTRR, you can choose any layout of the target table. So when you GTRR from an anchor TO to a buoy TO, you can choose the layout that's associated with the anchor TO of the target table. There's no need for any complicated workarounds (unless I am missing something in your description).

 

[cwcrogan]

comment, thank you!

Quote

When you GTRR, you can choose any layout of the target table. So when you GTRR from an anchor TO to a buoy TO, you can choose the layout that's associated with the anchor TO of the target table. There's no need for any complicated workarounds (unless I am missing something in your description).

I had a feeling I was over-complicating things. When I first broke it I immediately headed in the wrong direction. I just changed the GTRR and layout and it works perfectly with no workarounds.

Quote

 

A multi-value key can be used instead of a join table provided that:

1. The join itself has no properties; and
2. You do not need to produce a report of hydrants by address (or vice versa).

 

The multi-value key is just a list of IDs, no properties. Haven't fully grasped the reporting yet, but I think I can script a workaround if I needed it.

Thank you again!

[comment]

1 hour ago, cwcrogan said:

The multi-value key is just a list of IDs, no properties.

I don't think we're talking about the same thing. Of course a multi-value key has no properties other than IDs. But suppose that in addition to associating an address with a hydrant you also want to record the distance between them. In such case a multikey cannot replace a join table.

 

56 minutes ago, cwcrogan said:

 Haven't fully grasped the reporting yet, but I think I can script a workaround if I needed it.

Sure. As long as the workaround is less work/complexity than a join table.