I started this quest under the following: http://drupal.org/node/89171

but, now that i think i have found the bug; i figured best to open this as a new bug specifically against the wrapper module

tax wrapper module:

under function taxonomy_node_save {}

around lines 564:

     else if (isset($term->tid)) {
            db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term->tid);
          }
          else if ($term) {
            db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term);
          }

under the else if ($term) part the db_query is passing $term - at this point $term is an object and i think is not what is expected here - although my guess is that it evaluate to TRUE and therefore a 1 which is what is gettingstored in the term_node table for all my tid's

If i change $term to $term->nid, things seem to work correctly

Since no one seems to be reporting this; i can only assume that it has been fixed in CVS; and i will check to see if it is - too bad not an easier way to see required patches, etc for modules.

Comments

liquidcms’s picture

liquidcms commented

i just checked CVS Oct 15, 2006 and the code is the same as the veriosn i have been using - so possibly i am still missing the point here somewhere... but pretty sure $term can't be right here.

bdragon’s picture

bdragon commented

Hmm....

This issue definately needs further investigation...

This issue has been reported before: http://drupal.org/node/87669

Could you get a var_dump of one of the $term objects that is failing?

liquidcms’s picture

liquidcms commented

this is var dump of $term from tax wrapper when i try to re-save an image node:

object(stdClass)(8) { ["nid"]=> string(2) "12" ["node_id"]=> string(1) "6" ["cid"]=> string(2) "12" ["cnid"]=> string(2) "11" ["description"]=> string(0) "" ["weight"]=> string(1) "0" ["depth"]=> string(1) "0" ["title"]=> string(8) "examples" }

and, still pretty sure that db_query() function can't accept an object ($term) as a parameter.

liquidcms’s picture

liquidcms commented

ok - my bad.. sort of..

for some reason i managed to miss Jeremy's (jaza's) article on views and categories: http://category.greenash.net.au/category_views_usage

which states :

Note: neither category nor category_views currently implements the hooks provided by the views module. For this reason, in order to make effective use of category_views, you will need to have the taxonomy wrapperi installed.

this article is great - it shows exactly how to do what i wanted to do - which is theme a category (basically)

all this being said; i think the bug is still a bug since i dont think you can pass an object to the db_query function - but posibly few poeple have stumbled upon this since they use Jeremy's approach to "filtering" for a category - i.e. by passing TermID as argument

Henrik Opel’s picture

Henrik Opel commented

I think I found the reason for all the tid's in the term_node table ending up as 1. See the already mentiond http://drupal.org/node/87669 for details (second patch, the first one is a questionable ad-hoc fix of the symptoms only, IMHO).

After that change, the tid's get inserted/updated in the term_node table, which makes views work without the category_view module also (of course you still need it, if you want the views showing up on the container/category pages itself, which AFAIK is the main purpose of that module).

Oh, and *don't* use the $term to $term->nid approach! This only prevents the database from spitting out errors, since it gets proper IDs to insert, but those will be wrong IDs that will corrupt your data integrity and might lead to pretty weird results!

(foreign keys anyone? ;)

bdragon’s picture

bdragon commented

Drupal doesn't use foreign keys or auto_increment fields.
Drupal generates its own IDs. (see the sequences table)

Henrik Opel’s picture

Henrik Opel commented

Um, well - I noticed, that's the reason for the remark :)

Nothing wrong with a program maintaining its own sequences, but not using foreign keys seems unneccessary risky to me (eg. a table filling up with non-existant id 'references' as in this case would not go unnoticed).

But I don't want to complain or critisize drupal - I'm quite happy I've found it, and it fits my current tasks quite nicely :)

Therefore a question on a more constructive note: As mentioned in the 87669 thread, I'm quite new around here and not sure about the way things get handled. As bdragon mentioned, this issue seems to be the same as the 87669 one, and I think (hope ;) I fixed it. Should I then just close this one with a remark linking over there? (And even if it wasn't fixed, should'nt this be done anyway to prevent seperate threads on the same issue?)

Henrik Opel’s picture

Henrik Opel commented

Ok, on rereading my questions above (and realizing that there is a 'duplicate' entry available for the status) I feel kind of stupidly overcautious - preventing seperate threads on the same issues is probably the right approach in every community. So I'll be bold and mark this as duplicate ... ;)

Henrik Opel’s picture

Henrik Opel commented
Status: Active » Closed (duplicate)

Marked as duplicate, see following issue to continue:

http://drupal.org/node/87669