From: Chetna W. <ch...@ar...> - 2003-03-07 16:44:55
|
Hi Jonathan, Thanks for the mail. I was thinking how the script would work without the --commit option and your explanation has clarified that and helped to clear my assumptions. Thanks Chetna > That's not quite true (or at least it shouldn't be); without the --commit > option the plugins will still do all of the same inserts that they would > do with the --commit option. By default these inserts are all performed > in a single transaction and until that transaction is either rolled back > or committed, it is true that *other* transactions won't be able to see the > new rows in TaxonName (or Taxon, actually, since the reference in question > was TaxonName.taxon_id.) However, the plugin itself *should* be able to see > the new rows in Taxon/TaxonName, so long as it doesn't roll the transaction > back and start a new one. The crucial thing to realize is that a table can > appear to be empty in one transaction/session, but not empty in another. > So even though the Taxon table might not contain any rows that have > been committed, it could still contain rows that are visible to the plugin > itself (and that could be used to establish a foreign key constraint from > TaxonName.) The crucial question (I think) is whether the plugin is doing > a commit or rollback between the time it inserts the Taxon rows and the time > it inserts the TaxonName rows. I don't think I've looked at this code but > it should be easy to figure out why it's getting a null taxon_id and it should > be possible to get it to work in no-commit mode. |