This issue is about not optimal code patterns being used in the actions system. I'll try to make a little introduction to the issue.
Certain actions can have parameters, which are stored as serialized data in a "parameters" field in the table.
When dealing with actions, the current approach in core is to directly select actions from the actions table and deal with the rows directly. This means manually unserializing the "parameters" field each time you get a row from the actions table.

Current code also provides an actions_load($aid) function which consists of just a db_fetch_object/db_query call. This function is used only once in all the core codebase.

This patch suggests the introduction of a new function called actions_unpack($action) which takes an $action database object and unserializes the parameters field. It also corrects the code in actions.inc and system.module to conform to this new change.

The pro's for this patch are:
* a little cleaner code throughout core;
* the actions_unpack function could be easily extended with a hook to be able to manipulate actions parameters and for example, make them language-aware (see #340657: Save actions settings by locale for details)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

flevour’s picture

FileSize
3.31 KB

I attach a patch rolled against Drupal 6 just as an example.

flevour’s picture

Rolled against D7. In system.module it saves the rewrite of a query too :)

snufkin’s picture

Status: Active » Needs work

The code itself does look cleaner, but it could be more.

It introduces two new functions, actions_load and actions_unpack. The only purpose for actions_unpack is to unwrap the parameters field, and thus it is used when actions are loaded in actions_do.

Implementing an actions_load is a great idea, but lets go one step further! The idea in these load functions is to separate the SQL handling into one function, and let the rest of the code just do its stuff. Doing so we can get rid of the actions_unpack, since its functionality would only be needed in actions_load, moreover we could also remove the SQL from actions_do. This needs an extension to actions_load, some way to pass those WHERE conditions into the loader.

flevour’s picture

Hi snufkin, thanks for the review.
The purpose of having actions_load separated from actions_unpack is there are scenarios where you want to _unpack an actions db row that doesn't come out of an actions_load. For example in the patch you can see the first hunk using action_unpack while looping through a "SELECT * FROM actions" db result.
Does this make any sense?
One more possibility would be to make a refactored actions_load which can take as argument either an $aid (or an array of $aids, as node_load) or nothing and return the selected actions or all the actions respectively. This way actions_load could contain the logic that I have put in the actions_unpack function.
Cheers,
Francesco

flevour’s picture

FileSize
3.36 KB

Re-rolling against head, chx spotted a construct error.

snufkin’s picture

For example in the patch you can see the first hunk using action_unpack while looping through a "SELECT * FROM actions" db result.
Does this make any sense?

Yes, i completely understand, my suggestion was to remove the need to have a "SELECT * FROM actions" db result at all, and be able to load the actions fully with actions_load.

Jooblay.net’s picture

Issue summary: View changes

What is the status of this ticket:) Can we close this...