Merging produces SQL error in entities with Link fields(maybe other fields)

I am getting this problem to. TfR75 - did you do this using user #1?

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1: INSERT INTO {field_data_field_link_original} (entity_type, entity_id, revision_id, bundle, delta, language, field_link_original_url, field_link_original_title, field_link_original_attributes) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, ); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 204 [:db_insert_placeholder_2] => 209 [:db_insert_placeholder_3] => video [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => http://www.youtube.com/watch?v=QI-QzFrM6bk&feature=youtube_gdata [:db_insert_placeholder_7] => ) in field_sql_storage_field_storage_write() (line 424 of /example.com/modules/field/modules/field_sql_storage/field_sql_storage.module).

Based upon the error stating that it's a "Syntax error or access violation," It would seem that it is an access error. #1234906: Permissions not applied correctly, authorised role cannot merge terms would support this theory.

Where do you even see the option to merge? Can't see anything on the edit term page.

@oskarrough see #1262810: Use a tab or a link instead of the "merge" button

This is not necessarily an access violation, it could be a string problem related to a specific field. i am checking the corresponding fields.

Is it me or there is a missing placeholder?

Patch here worked: http://drupal.org/node/1234906#comment-5170326

#8 didn't work for me.

this link is already in this thread somewhere... ;-)

Hi, I wrote the patch linked in #8. I think this is a different problem.

The solution is to call "field_attach_presave" before you call "field_attach_update. I have attached a patch.

I found this problem with a entity(a node) that a had a Link field. As you can see in error at the top of the page. The SQL insert statement has 9 field names but only 8 values given. This causes the error.

field_attach_presave calls hook_field_presave which some field modules will use to add other info to the fields. The Link module uses this hook to add an empty "attributes"(the value that is missing) array if know is on the field.

changing the title to be more descriptive of what is actually happening

tedbow, it worked! thanks.

but just so I will understand, If there is a problem with the link field module and its save process, it needs to be fixed. we are just hiding a problem and causing some over-processing...

ymeiner , I don't think it is necessarily a problem with the link module. I think it is reasonable for a module to expect "field_attach_presave" to be called before "field_attach_update". This is how it happens in internally in both user_save and node_save(probably other entities too).

From the docs for field_attach_presave - http://api.drupal.org/api/drupal/modules--field--field.attach.inc/functi...

Perform necessary operations just before fields data get saved.
We take no specific action here, we just give other modules the opportunity to act.

Kind of like calling node_submit before node_save.

Hi guys, thank you for your contribution, the patch has been committed to the latest dev release. I'm sorry but I missed this patch before I created the beta-2 release, but It will come with the beta-3 later!

Sorry about the time it took for me to get it in...

At the project page there is no 7.x-1.x-dev release and the beta3 has yet to come. Is it possible to publish a fix to the main project page, even in 7.x-1.x-dev release?

This module comes in very handy, and although I know how to checkout by git many other people might not be acquainted with it.
Of course git HEAD works fine!

ps: sorry for re-opening this issue

Hello, bserem. No worries about reopening the issue.

This module has been orphaned, and about a week ago I took it over. An hour ago I have commited a deep rewrite of coding. Please, download 7.x-1.x-dev from the project's homepage and test it. It should be functional and bugfree, yet I let people test it before we publish a release. Unfortunately, since I did complete rewrite the patches mentioned in this issue no longer apply, but as I said, I am pretty positive this dev is stable and close to be released.

Report any bugs please.

@bucefal91 please, don't push major rewrites of the code to the same branch unless your changes are backward compatible. I know there are no hard rules for unreleased modules, but this one is in use in several production environments...

Also, if you want other developers to review your code, post patches and wait for commentary before commiting ;) See http://drupal.org/node/363367 for more on contributing best practices.

The public interface for the module has not been changed (term_merge() - I can see this one as the only public API of this module), and only slight changes have been implemented in the UI of the module. Please, try it out and let me know if it's not backcompatible. However, I plan to have it released as 7.x.2.x version, because this project already has tag 7.x-2.0-beta2 , which I am not sure how happened, because it dones't even have 7.x.2.x-dev right now in its repository.

you can go directly up to 7.x-3.x then, nobody will argue with you about it :)

I'll test your code tommorow morning.
Congratulations and bravo for taking over this module. While it is not a common everysite needs, when you need it it is a life saver!

Yep, this module is handy, I need it for a project of my own. Please, review. If you think it's better place for it in 3.x branch, just let me know and I will revert my commit and instead create a new branch, which will be home for that code. Sorry for committing into 1.x, I am new to Drupal.org coding and branch standards, I've been a developer, but I never uploaded stuff on drupal.org. If in other issues people will start complaining about reverting this commit and demanding me to put in another branch, I'll also follow their requests, because basically my main mission is to have you guys satisfied, isn't it? :)

Actually, your mission should be just building a working solution, and letting us (the community at large) improve the solution either with bug reports or feature requests (and corresponding patches). As for conforming to Drupal contributing standards, they're there for a reason (preventing upgrades from eating our sites, for one good reason).

Anyway, welcome to the project maintainer world :) Enjoy!

new -dev works nice :)

good job

Usually, we post patches, let third-parties test the patches and finally commit them. Seeing these changes are already commited, I'd say there's nothing to review here — any bug report or feature request we get will be new issues.

Therefore, this issue is "fixed". If there's no report re-opening this issue (moving it back to "needs work") in the next two weeks, it will be set to "closed (fixed)" automatically.

@bucefal91 see http://drupal.org/node/156119 for dealing with issues statuses. @bserem might find it useful as well.

barraponto, thanks for the heads up. I am trying to understand the workflow and ideology of issue tracking/project development at drupal.org. I see what you mean, in another project that I maintain now, instead of committing into -dev and letting people try, I attached a patch to the issue and put the corresponding status. Thank you again for mentoring :)

Well as a module maintainer I think it is quite normal to commit directly to dev without prior posting a patch.
However I agree using 3.x dev would be more secure and easier to understand and there you could change the public interface as well if need be. :)

Just a small note regarding future commits: Git lets you split up your work into small chunks that you can commit locally before pushing to d.o. For us and yourself it will be easier to go through the code changes later that way.