Needs review
Project:
Image
Version:
6.x-1.x-dev
Component:
image_attach
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Mar 2010 at 00:53 UTC
Updated:
20 Sep 2010 at 12:45 UTC
Jump to comment: Most recent file
I found this modification when updating a clients modules and figured it be useful so I made a patch.
It makes image_attach link to the nodes vid instead of nid so you get revision support.
Hopefully I've done the oracle & pgsql support properly.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | image-image_attach_revisions-752288-13.patch | 9.11 KB | agileware |
| #6 | image-image_attach_revisions-752288-6.patch | 8.91 KB | agileware |
| image-image_attach_revisions.patch | 3.79 KB | agileware |
Comments
Comment #1
joachim commentedThanks for making the patch :)
It would need rerolling for D6 though, and the update function id changing to the normal standard.
However, I'm not sure whether it's a good idea to make this big a change at a time when we're inching towards a full 1.0 release. On the other hand, while this is a big change it's a pretty simple patch, and in some ways it's better to make a change like this while in beta than for a 1.1.
I'll ponder it and discuss with the other maintainer.
Comment #2
agileware commentedNo worries, I'm sure I can port it to 6 if need be
Whoops, forgot to set the status
Comment #3
sunNice one. Actually could be considered as security hardening, too.
Instead of replacing nid, we need to add vid.
Doing so will ensure backwards compatibility to some extent.
However, perhaps I overlooked something, but this patch doesn't seem to address the forward-copying/forking of existing values for new node revisions?
Powered by Dreditor.
Comment #5
joachim commentedIt would be great if this could go into the 1.0 release, but I don't have the energy or focus to work on this at all.
@Agileware: any chance you could look at this patch again?
Comment #6
agileware commentedHere is an updated version of the patch that adds vid instead of changing nid to vid.
It also addresses an issue that would have occurred with the old patch where you could get duplicate rows in the image_attach table if you save a node without creating a new revision.
Comment #7
agileware commentedHopefully I'm not treading on anyone's toes by removing this section entirely. I couldn't see a point to it and it was creating bad rows in the database for new nodes. Plus in my testing everything still works as expected. But if I was hasty in removing it let me know.
Powered by Dreditor.
Comment #8
joachim commentedThat's in image_attach_image_add_submit() which is the handler for the 'Upload' button.
I don't see why that needs to delete and then update the database, since it's taking us back to the form afterwards. Anyone else got thoughts on this?
Comment #10
sunThanks!
Should be {image_attach}.vid, not "node vid"
Starring at the essentials of this code, I can only guess that it is trying to prevent duplicate weight values, as that seems to be the only thing that is actually changed.
However, regardless of whether that is actually needed, the code is surely at the wrong wrong location, since the submit handler basically inserts the new rows already, whereas the API functionality in hook_nodeapi() is actually responsible for data storage, which it already does, and so it seems like we're inserting at least twice here. Though I'm not sure whether we properly take care for the weight values.
Should wrap at 80 chars, and more importantly, we might want to try to explain why we are entirely replacing all rows, instead of just doing what D7 would call a merge query (i.e., inserting new rows or updating existing rows accordingly)
Should use (int) casting.
Powered by Dreditor.
Comment #11
joachim commented> instead of just doing what D7 would call a merge query (i.e., inserting new rows or updating existing rows accordingly)
Is there a nice way to do that on D6? Every module I've seen has this pattern of 'delete all rows for the node, put them all back in again'.
Comment #12
sunUnfortunately not - and on MySQL, db_merge() effectively is just a short-cut for
(pseudo-code)
Comment #13
agileware commentedNew patch that addresses sun's comments in #10.
It also should pass all tests now.
I agree that image_attach_image_add_submit() definitely shouldn't be doing database updates as they are done in nodeapi and
I think weights are handled well enough, considering the user doesn't really have any option to set the weight.
I struggled a little thinking of a comment for the delete/insert sql so feel free to tweak that.