Posted by schildi on April 4, 2007 at 10:28am
2 followers
Jump to:
| Project: | Category |
| Version: | 5.x-1.1 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
When creating a container as the first entry by "category" a message raises that a duplicate key was found.
The module tried to insert a row into vocabulary with VID=1, but there was already a row with this ID created by module "image_gallery".
Image_gallery seems to create a first entry into vocabulary at installation time (see image_gallery.install).
Regards
Schildi
Comments
#1
The VID is inherited from newly created category-node, so I assume this is on a completely new site, where the new container is very first node created (nid=1 --> inherited as vid=1 through taxonomy wrapper legacy code). If there was another vid=1 record already created by image_gallery, I believe that's because image_gallery was installed [first enabled] before Category was up and running [i.e. before the category module, and taxonomy wrapper got both installed], so that this vocabulary got created through core taxonomy module instead, and Category doesn't have any knowledge about it.
So, if I am right, this is a bit of edge case: A coincidental conflict between out-of-sync node and taxonomy data, happening on legacy taxonomy [created pre-category-install] being not properly imported [category_legacy job]. And yes, category_legacy would likely have a similar sequencing conflict too, but that's another issue (#59163: legacy taxonomy import sometimes has sequencing conflicts). You're also likely to have problems later, because you'll need to maintain your category structure for the gallery container with Category, which won't work with the container node missing (the node certainly wasn't there, if another one of the same NID got created in your case).
The proper way to handle this, in my opinion, is: Install Category module first, enable taxonomy wrapper, and only then install any taxonomy-dependent modules, so that the taxonomy wrapper is used by these modules consistently from the very start. Or else try category_legacy to fix that stuff. Also test compatibility of your modules with category module, as there's always a bit of risk...
While it's questionable whether this deserves a mention in README.txt or somewhere, I don't see it as a category module bug (or at least not one that may be fixed - how do you fix implications of incompatibilities happening before our code gets even first loaded? Only by cleaning up afterwards, which is already offered in category_legacy.)
Since this issue is over 2 years old, silent, and about 5.x version (not really supported), I'm going to just close it now. Feel free to disagree/re-open, if needed.