Circular dependency references between field and field_sql_storage [#896698]

Testing for making a visual dependencies graph I ran into a circular dependency.

field.info
dependencies[] = field_sql_storage

field_sql_storage.info
dependencies[] = field

Removing the dependency of field.info to field_sql_storage would make my pain go away but there is a subtlety here.

_module_build_dependencies does not report back the circular dependencies. Either drupal_parse_dependency or drupal_depth_first_search is buggy by subtle removal of this circularity.

I'll try to investigate this further.

Comments

Comment #1

Damien Tournoud CreditAttribution: Damien Tournoud commented 29 August 2010 at 17:24

This is by design. When passed a non-DAG, the order that is returned by drupal_depth_first_search() is not the topological order (which doesn't exist), but something "close enough" for our purpose.

We should remove the dependency of the field module on the field_sql_storage module. But there is a small twist: we might need to add the later to the list of modules automatically installed by our installation profiles.

Comment #2

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 29 August 2010 at 19:30

Hmmm ... the documentation does not state anything about the result of a call to

/**
 * Perform a depth first sort on a directed acyclic graph.
 *
.... */
function drupal_depth_first_search

Note: passing in a non-DAG will produce unexpected results

something?

And how to we solve #1's we might need to add the later to the list of modules automatically installed by our installation profiles

Comment #3

LaurentAjdnik CreditAttribution: LaurentAjdnik commented 29 August 2010 at 20:20

Subscribing

Comment #4

yched CreditAttribution: yched commented 29 August 2010 at 23:37

See also #893880-6: Field_sql_storage.install uses field crud api files without them being included, which has a patch to remove the circular dependency.

Comment #5

marco71 CreditAttribution: marco71 commented 7 October 2011 at 12:49

Subscribing

Comment #6

Advocat CreditAttribution: Advocat commented 18 August 2012 at 13:22

Subscribing

Comment #7

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 18 August 2012 at 14:37

Assigned:

clemens.tolboom

» Unassigned

@Advocat why are you subscribing? Have you ran into trouble?

Comment #8

Advocat CreditAttribution: Advocat commented 18 August 2012 at 14:49

Yes. See: http://drupal.org/node/1734826

Comment #9

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 18 August 2012 at 15:09

@Advocat : It would help to make a summary of that post here as a comment.

You could also try to install http://drupal.org/project/graphapi to get a graphical representation of the modules as a whole. (Not sure whether it helps)

If you can list 'Steps to reproduce' I will try to follow those to test myself.

Comment #10

Advocat CreditAttribution: Advocat commented 18 August 2012 at 23:13

Summary: On a social networking site I'm building, I attempted to disable all modules.

After disabling all active (black checkmarked) modules and saving, there are a number which remain grey-out, making it impossible to disable them.. Research suggests there is a file field dependency issue, but it's impossible for me to determine which is the base cause.

I did check the field_config table, as some forum entries suggested. There were 30 items there, all using Field SQL Storage as the storage type and module. The database listed module which implements the field type echoes (in part) the modules which cannot be disabled ; I've marked those below with an asterisk ( * )

Present core is 7.14

Modules which cannot be disabled:

Chaos tools
Entity API
Entity reference *
Field
Field SQL storage
File *
Filter
Image *
List *
Node
Options
Organic Groups *
System
Taxonomy *
Text *
User

I uploaded graphapi as suggested, but I can see no obvious revelations -- and admittedly, this is the first time I've worked with graphapi -- with the exception of:

There is a sole circular dependency between Field and Field_SQL_Storage modules, and
All the above-listed modules are tightly interwoven in dependencies
It appears that all locked modules are in a chain: either dependent directly on Field. Or on the Text / Options / List / File modules (dependent on Field). Or on Organic Groups (OG is dependent on Text, Options, List) or on a module which is dependent on OG.

Comment #11

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 19 August 2012 at 12:29

I did the following with Drupal 7 head (7.16-dev)

drush --yes @drupal.d7 sql-drop
drush --yes @drupal.d7 site-install
drush --yes @drupal.d7 dl ctools entity entity_reference og
drush --yes @drupal.d7 en og
drush @drupal.d7 uli
drush @drupal.d7 pml --pipe --status=enabled

Next trying to disable field which should not work

drush @drupal.d7 pm-disable field

gives

text is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
field_sql_storage is a required module and can't be disabled. [ok]
field is a required module and can't be disabled. [ok]
image is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
og is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
taxonomy is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
The following extensions will be disabled: options, comment, file, field_ui, list, number
Do you really want to continue? (y/n): y
comment was disabled successfully. [ok]
field_ui was disabled successfully. [ok]
file was disabled successfully. [ok]
list was disabled successfully. [ok]
number was disabled successfully. [ok]
options was disabled successfully.

That figures as the content types: Article and Page are there.

Deleting all comment fields and then content types

drush @drupal.d7 pm-disable field

gives new information relating to pending deletion.

text is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
field_sql_storage is a required module and can't be disabled. [ok]
field is a required module and can't be disabled. [ok]
image is a required module and can't be disabled. Reason: Fields pending deletion [ok]
og is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
taxonomy is a required module and can't be disabled. Reason: Fields pending deletion [ok]
The following extensions will be disabled: options, comment, file, field_ui, list, number
Do you really want to continue? (y/n): n
Aborting. [cancel]

Pending fields thus run cron.

drush cron
Cron run successful.[success]

Now we should be able to delete more.

drush @drupal.d7 pm-disable field
text is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
field_sql_storage is a required module and can't be disabled. [ok]
field is a required module and can't be disabled. [ok]
og is a required module and can't be disabled. Reason: Field type(s) in use - see Field list [ok]
The following extensions will be disabled: options, taxonomy, comment, file, image, field_ui, list, number
Do you really want to continue? (y/n):

Disable as much as possible

drush @drupal.d7 pml --pipe --status=enabled --pipe | drush pm-disable

it is impossible to disable the last modules

drush @drupal.d7 pml --pipe --status=enabled
field
field_sql_storage
filter
node
system
text
user
bartik

Visiting the modules page shows some depending on Drupal.

Conclusion:
- it is not possible to disable all modules like user and node
- most are not related to a circular dependency but mere entity related (user, node). I'm not sure why text could not be disabled after trying to disable all.

The circular dependencies for field and field_sql_storage is still in Drupal 7.

Was this useful?

Comment #12

Advocat CreditAttribution: Advocat commented 20 August 2012 at 12:06

Thanks clemens.tolboom, it was informative. To be honest, module analysis via drush is something I have no experience with. I am most definitely not a coder/developer on that level. If I am understanding your analysis properly, it is the creation of certain entities which is creating the lock.

Let me ask a practical question as a Drupal user/admin. Should, at some point, a major upgrade to D7 be released which requires disabling all modules (as happened at least once under D6), or should I wish to upgrade the site to D8 in the distant future, what steps should I take to disable the modules and conduct the upgrade?

Or is the case such that I would simply install the upgrade as a new install, and rebuild the site/project from scratch?

BTW, let me than all who have responded to my question. I've always found the Drupal community to be exceptional in the willingness of experienced members to help those with less experience.

Comment #13

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

CreditAttribution: clemens.tolboom commented 21 August 2012 at 10:31

@Advocat: see http://drupal.org/upgrade for hopefully more explanations about update/upgrade.

Regarding a D6 to D8 major upgrade you should go through a D6 to D7 then D8 upgrade or use migration tools.

The http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/UPGRADE.txt to D7 you should disable all non core D6 modules before upgrading to D7.

Hope that helps :)

Comment #14

Cameron Tod CreditAttribution: Cameron Tod commented 22 August 2012 at 18:13

Advocat, a major version upgrade can be a big undertaking, depending on how complex your site is. I've been working since January with four other devs on a D6->D7 update, for example :)

If this is something you're interested in learning about, check out Migrate module and Drupal-to-Drupal data migration. They've been a great help to us.