Expected:
- Create an Amazon item node using the example content type
- Look at the example view and see the one book
- Edit that piece of content and change the ASIN
- Look at the example view and see the new book
Actual:
- Create an Amazon item using the example content type
- Look at the example view and see the one book
- Edit that piece of content and change the ASIN
- Look at the example view and see both the new and old book
- Delete the node, leaving you with absolutely no amazon content
Workaround:
- If you want a book to go off of the list, delete the node
- If you get the orphan, browse your Drupal database, the amazon_item table, and delete the orphan record
Comments
Comment #1
rfayThanks for the nice, detailed report. I'll try to resolve this when I next work on the module.
Comment #2
manji51 commentedNo problem! I went back to test it again (since I didn't actually verify I could recreate the bug after I ran into it the first time). Other than being successful at recreating using the steps outlined above, I also found a different workaround:
Comment #3
rfay@manji51: I failed to ask you what actual harm is done by this basic behavior, but you describe some harm.
However, you describe behavior that I can't replicate (I tried the steps you mentioned)
The Example view is a view of *nodes*, and I don't get this and shouldn't.
If you created a view of Amazon Items (which is not very useful) you would see this.
Can you please provide your content type and view?
Please test with the stock view (revert to the stock view) which is a view of nodes and has a required relationship to an ASIN.
Please mention the version of views and cck you're using as well.
Thanks,
-Randy
Comment #4
manji51 commentedI don't believe this has anything to do with Views. As I noted, it is leaving orphans in a database table that seems to be picked up by the view, but the problem is really the orphan item in the database table, right?
I believe this could be sufficiently tested without ever touching Views. Removing the steps that include viewing which items display on the view doesn't actually remove any function from seeing the bug.
It looks like I have a painfully old version of CCK!
Content Construction Kit (CCK) 6.x-2.x-dev (2009-Dec-04)
This is unacceptable. I'll test this over again after updating CCK.
Comment #5
rfayYou say "I don't believe this has anything to do with views" but your but report is stated in terms of what you see in the example view.... I was unable to recreate your results using the example view.
I'm quite certain that orphans are left in the database in the scenario you describe. I'm just not convinced there's any harm in it.
Comment #6
manji51 commentedAnother question about #3:
Doesn't this module create the "Amazon Items" view type? If it does, it seems a little incongruous to say it's not very useful.
#5:
I don't think I can constructively reply to this. I see a problem with database orphans.
Comment #7
rfayNo, the Amazon Examples view provides a node-type view only. It's easy to create a view of amazon items, and it may be useful for something (probably administration?) but it's not generally useful, since it has no relationship to drupal objects that you can show on the site.
Please try out the node-type view provided by the Amazon example. I think you'll like it.
Patches and contributions are welcome, so if you would like to take a shot at improving the behavior with database orphans, give it a shot.
You have to remember how this works: I've spent most of the last week and a half updating the modules that I maintain to Drupal 7. I haven't done any billable work in that time. There is no "they" in Drupal. No "they ought to fix this". It's just a bunch of us folks working on stuff in our spare (and not spare) time. You're encouraged to join in.
Comment #8
rfayNotes on this bug:
Currently the amazon_item table is the one place where all Amazon features find an item. So it might be used by a filter, a CCK field, etc. Thus it's difficult to know when an item in the table is orphaned.
Deleting the items in the table does no harm *except* in the case of views. Views cannot properly operate on anything unless it finds the correct items in the table, and if they get inappropriately deleted, they can't be recreated except by visiting the page which has the cck field or filter on it.
The normal Views usage is to use a node-type view, even though the direct view of Amazon items is easy to create. So the extra items in the amazon_items table are normally just a bit of a waste of space. I will keep in mind that there may be a way to reconcile the state of amazon_items in the future. Perhaps this could be done in cron. It would require looking for all content types that have an amazon item, finding all the asins referenced, and then checking the results. That wouldn't be too terribly hard, and could be done by cron perhaps.
For now I'm going to mark this "will not fix" but can be convinced otherwise, or a community contribution can solve it. There are just too many other things to do.
Comment #9
rfayInterestingly enough, as a result of this discussion I ran across another discrepancy related to this on the D7 port. When you delete a node, it deletes the items in the fields on the node... including any amazon_items referenced there. But what if more than one node has references to that amazon_item? Well, any view of it no longer works.
The correct perfect behavior would be to keep a reference count in the ASIN. Every ASIN field that references it would increment the reference count.
* On update OR delete: Decrement the reference count of the old. If it has dropped to zero, delete it.
Probably this needs to be done.
None of this affects your original complaint, as that was a result of using an amazon item view instead of a node view.
Comment #10
manji51 commentedAhh. I did not know about the possibility of multiple nodes referencing the same item in amazon_items. This makes more sense to the not deleting the item.
Comment #11
panchoI'll take care of this. Needs to be backported to 6.x
Comment #12
willvincent commentedComment #13
smitty commentedIt seems that the items in the amazon_items do not get delete even if the product is not provided by Amazon any more (if amazon_item_lookup_from_web returns zero).
It also seems to me, that views accesses directly to this table and does not use amazon_item_lookup (might that be?). The view contains data from this table with a timestamp some months ago.
The outcome is, that in my views I get Amazon data (price, link), that is not valid any more. I think this is against the Amazon Licence Agreement.