Multiple Table Blocks - Dealing with bID Changes
Permalink
So, I have seen this question bandied about several times, but I have no definitive answers. I'm going to summarize what I am dealing with, and see if anyone can aid me to best understand this.
I am doing a multiple DB table block. The main table is for the block proper, and it contains a title and some other details. The secondary table is a list of items that make up the body of the block. It also has several fields for parsing.
Due to versioning, the bID changes every time the block is edited. However, as this is the foreign key for the secondary table, it needs to get updated as well.
I see that the slideshow block (the best comparison to what I am doing) basically grabs all the db info, deletes the old info, and then recreates it, then calls the parent save method.
However, I am unsure where this db call gets the new bID from. It seems to do it right after deleted all the old info (lines 175-183).
I have no issue with that concept per se, and I will be doing the editing of the sub table via ajax most likely, so that is a moot point as well.
I guess I just need to know precisely how to update the bID for the secondary folder using best practices. I don't mind doing an update in the db once the new bID is generated to move the numbers up, but where would that call go?
I am doing a multiple DB table block. The main table is for the block proper, and it contains a title and some other details. The secondary table is a list of items that make up the body of the block. It also has several fields for parsing.
Due to versioning, the bID changes every time the block is edited. However, as this is the foreign key for the secondary table, it needs to get updated as well.
I see that the slideshow block (the best comparison to what I am doing) basically grabs all the db info, deletes the old info, and then recreates it, then calls the parent save method.
However, I am unsure where this db call gets the new bID from. It seems to do it right after deleted all the old info (lines 175-183).
I have no issue with that concept per se, and I will be doing the editing of the sub table via ajax most likely, so that is a moot point as well.
I guess I just need to know precisely how to update the bID for the secondary folder using best practices. I don't mind doing an update in the db once the new bID is generated to move the numbers up, but where would that call go?
Sort of. I'm seeing a few of them referenced in other blocks, but most of them have the new bID as an argument. The question remains - where does the new bID come from?
There is a block versions table that chains back through the versions of a block by bID. In some of my work, where the version of the block was not relevant to the secondary table, I used that to track down any previous bID that my data was associated with.
Where data maps to the block, an easier solution may be to store the secondary data serialised in an X2 field of the block. (as long as you don't need sql to filter on it).
Where data maps to the block, an easier solution may be to store the secondary data serialised in an X2 field of the block. (as long as you don't need sql to filter on it).
Hope that this tip helped
Mike