Hi guys!
I have the following table in the opencyto_quality_control schema:
CREATE TABLE opencyto_quality_control.stats
(
Container ENTITYID NOT NULL,
sId INT NOT NULL,
fileId INT NOT NULL,
gsId INT NOT NULL,
population TEXT NOT NULL,
stats TEXT NOT NULL,
node TEXT NOT NULL,
channel TEXT NOT NULL,
value NUMERIC NOT NULL,
CONSTRAINT PK_stats PRIMARY KEY (sId, Container)
, CONSTRAINT FK_stats_gsTbl FOREIGN KEY (gsId, Container)
REFERENCES opencyto_preprocessing.gsTbl (gsId, Container)
ON DELETE CASCADE
-- ,
-- CONSTRAINT FK_stats_meta FOREIGN KEY (fcsId)
-- REFERENCES opencyto_quality_control.meta (fcsId)
-- ON DELETE RESTRICT
);
<ns:table tableName="stats" tableDbType="TABLE">
<ns:columns>
<ns:column columnName="sid">
<ns:columnTitle>sid</ns:columnTitle>
</ns:column>
<ns:column columnName="container"/>
<ns:column columnName="fileid">
<ns:columnTitle>fileid</ns:columnTitle>
<ns:fk>
<ns:fkDbSchema>flow</ns:fkDbSchema>
<ns:fkTable>FCSFiles</ns:fkTable>
<ns:fkColumnName>RowId</ns:fkColumnName>
</ns:fk>
</ns:column>
<ns:column columnName="gsid">
<ns:columnTitle>gsid</ns:columnTitle>
<ns:fk>
<ns:fkDbSchema>opencyto_preprocessing</ns:fkDbSchema>
<ns:fkTable>gstbl</ns:fkTable>
<ns:fkColumnName>gsid</ns:fkColumnName>
</ns:fk>
</ns:column>
<ns:column columnName="population">
<ns:columnTitle>population</ns:columnTitle>
</ns:column>
<ns:column columnName="stats">
<ns:columnTitle>stats</ns:columnTitle>
</ns:column>
<ns:column columnName="node">
<ns:columnTitle>node</ns:columnTitle>
</ns:column>
<ns:column columnName="channel">
<ns:columnTitle>channel</ns:columnTitle>
</ns:column>
<ns:column columnName="value">
<ns:columnTitle>value</ns:columnTitle>
</ns:column>
</ns:columns>
</ns:table>
As can be seen, it references a table gsTbl from schema opencyto_preprocessing.
If a proper entry exists in the latter table, then the stats table can be correctly populated and in the 'view' of the table one is even able to see the link with the value of the 'Name' column of the referenced row from gsTbl.
As soon as gsTbl is cleared, any tables refering to gsTbl from the opencyto_preprocessing schema in a similar fashion (via ON DELETE CASCADE), get cleared as well as expected, whereas the stats table from the opencyto_quality_control schema does not. Instead the link with the value of the 'Name' column of the referenced row from gsTbl turns into plain text with the gsId value surrounded with '<' and '>' !?
Why does this happen and how can I make it respect the ON DELETE CASCADE statement!
Thanks.
-Leo |
|
jeckels responded: |
2013-07-01 09:46 |
Hi Leo,
This is happening because the web server caches the list of values, and isn't expecting that there are "external" edits to the underlying tables happening.
I believe that you should be able to set your cache side to 0 to prevent caching, which should eliminate this problem. For reference, the default size is 1000. You can do that in your XML metadata for the table. You'll need to set the cache size on the foreign key target, or opencyto_preprocessing.gsTbl in this example.
Here's an example of XML that changes the cache size for a table.
<ns:tables xsi:schemaLocation=" http://labkey.org/data/xml ..\..\..\..\..\schemas\tableInfo.xsd" xmlns:ns=" http://labkey.org/data/xml" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance">
<ns:table tableName="PipelineRoots" tableDbType="TABLE">
<ns:cacheSize>5000</ns:cacheSize>
<ns:columns>
...
Thanks,
Josh |
|
Leo Dashevskiy responded: |
2013-07-01 11:51 |
Hey, Josh, this is pretty interesting.
So this caching mechanism is turned on only for the case when a table from one schema references a table in a different schema? (Because like I mentioned, I do not see this issue, when both tables are within the same schema.)
I tried modifying my table's metadata XML file like so:
<ns:table tableName='gstbl' tableDbType='TABLE'>
<ns:cacheSize>0</ns:cacheSize>
<ns:description>
The 'gsTbl' table contains information about generated gating sets.
</ns:description>
<ns:columns>
<ns:column columnName='container'/>
<ns:column columnName='gsid'/>
<ns:column columnName='gsname'/>
<ns:column columnName='objlink'>
<ns:columnTitle>objLink</ns:columnTitle>
</ns:column>
<ns:column columnName='gsdescription'>
<ns:columnTitle>gsDescription</ns:columnTitle>
</ns:column>
<ns:column columnName='xmlpath'>
<ns:columnTitle>xmlPath</ns:columnTitle>
</ns:column>
<ns:column columnName='samplegroup'>
<ns:columnTitle>sampleGroup</ns:columnTitle>
</ns:column>
<ns:column columnName='created'>
<ns:columnTitle>Created</ns:columnTitle>
<ns:formatString>yyyy-MM-dd HH:mm:ss</ns:formatString>
</ns:column>
</ns:columns>
</ns:table>
Shut down the server, then fired it back up, but the issue remains.
When the row in gsTbl referenced in stats is deleted, stats table does not get updated, but instead of the "fk" name link has the "<#>", where # is the id of the deleted row from the gsTbl...
Do I need to take any additional steps?
By the way, Ben iт one of my earlier posts mentioned that "LabKey appended brackets (<>) around the values", if there "are broken lookups" -- this seems to be the situation here.
But how could I avoid such a situation? I mean, ON DELETE CASCADE properly working would automatically solve it right away...
Thanks.
-Leo |
|
Leo Dashevskiy responded: |
2013-07-08 14:27 |
Would it be possible for anyone to reproduce my set up and then to either confirm (in which case some 'manual' solution would probably need to be implemented in order to get it to work properly) or refute my claim (in which case I will need to get to the bottom of why it is not behaving for me properly and to fix it)?
Thanks.
-Leo |
|
Leo Dashevskiy responded: |
2013-07-09 17:06 |
For some reason
CONSTRAINT FK_stats_gsTbl FOREIGN KEY (gsId, Container)
REFERENCES opencyto_preprocessing.gsTbl (gsId, Container)
ON DELETE CASCADE
though it is part of the original schema definition. Could it be that I did not run the update properly? :(
I was able through pdAdmin to properly create this foreign key across schemas relationship and the cascaded delete worked!
Now I have to figure out why I had to do this 'by hand' and the original definition did not kick in... |
|
Leo Dashevskiy responded: |
2013-07-11 12:47 |
The 'soft' Labkey-db-level foreign-key linking via the xml file worked, which led me to believe that the 2 tables are properly hooked up on the lower postgres-db level, which was not the case.
After a couple of attempts at linking them on the lower db level, it finally is working properly as expected. |
|
|
|