apachesolr_hook_info() calls entity_get_info() which can throw an error when installing using a profile.

That is pretty painful! Any link to the drupal core issue?

I ran into a different issue caused by the same reason:

http://drupal.org/node/1415278

Could this be resolved by added taxonomy as a dependency to the apachesolr.info file? At least for the time being?

Would there be another way we can fetch the entity types? Adding a dependency is not a long-term resolution. I'd suppose we could query the database? hook_hook_info is not a crucial one so I suppose that if we partly mimic the function it would work just fine?

The solution is to set a high module weight for apachesolr. That way it will be loaded after all other entity and hook info has been gathered.

Postponing, since it appears to be a drupal core issue, or until we can maybe find a way to get around this?

@Nick_vh how isn't adding the dependency a long-term solution when there's clearly a lot of queries in the apachesolr module that are directly referencing taxonomy tables.

This is an example of what happens when it's disabled:

WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'test.taxonomy_vocabulary' doesn't exist: SELECT name, machine_name, vid FROM {taxonomy_vocabulary}; Array ( ) in taxonomy_vocabulary_get_names() (line 856 of modules/taxonomy/taxonomy.module).

Basically, as long as the apachesolr module assumes the existence of the taxonomy module functions and tables, it needs to have a dependency on the taxonomy module.

When (and if) the code that makes those assumptions is refactored or removed, you can remove the dependency. Until then it is required.

Attached is the one-liner patch to add taxonomy as a dependecy.

@acbramley - I wasn't clear that you were pointing at adding the dependency as a solution. I found the solution of the weight not suitable as a solution.

Let's think this through. Would there ever be a site that uses solr without using taxonomy? And if so, should we rather hae if(module_exists('taxonomy)) in our module or what would be recommended here?
Any thought pwolanin?

Thanks for all the great input all!

I believe this is fixed with #1418834: Beta15+ problems with i18n and entity_translation.

I am running the latest beta 19 code, and without patch #10 this is the error that occurs on install or our custom install profile (that includes taxonomy and apachesolr):

Starting Drupal installation. This takes a few seconds ...                                                                                       [ok]
array_keys() expects parameter 1 to be array, null given common.inc:6880                                                                         [warning]
WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.taxonomy_vocabulary' doesn't exist: SELECT name,     [error]
machine_name, vid FROM {taxonomy_vocabulary}; Array
(
)
 in taxonomy_vocabulary_get_names() (line 884 of /var/www/drupal/modules/taxonomy/taxonomy.module).
Cannot modify header information - headers already sent by (output started at /usr/share/drush/includes/drush.inc:917) bootstrap.inc:1239        [warning]
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.taxonomy_vocabulary' doesn't exist: SELECT name, machine_name, vid FROM {taxonomy_vocabulary}; Array
(
)
 in taxonomy_vocabulary_get_names() (line 884 of /var/www/drupal/modules/taxonomy/taxonomy.module).
Drush command terminated abnormally due to an unrecoverable error.                                                                               [error]

With the patch #10 applied, I receive no such error.

In response to @Nick_vh I don't think there would ever be a drupal site that utilises apachesolr (advanced searching), and does *not* have taxonomy. In any case, I would love to see this trivial fix implemented whilst a more in depth discussion is held as to whether longer term the module should rely on taxonomy or not.

Moving over to this issue from a duplicate: #1439014: Error when using Apachsolr for install pofiles.

I am having the same issue as well. I attempted to fix this issue by applying the patch from #1418834: Beta15+ problems with i18n and entity_translation, which did not seem to make a difference. I also applied the patch in #10 which made the above error go away, but it was replaced by a similar error complaining about Table 'examplecom.rdf_mapping' doesn't exist

Removing the dependencies for the apachesolr and apachesolr_search modules from my .info file allowed the installation to finish without issue.

Regarding the wisdom of requiring taxonomy as a dependency for apachesolr, I would have to say that while I can't see a good use for apachesolr without the faceting provided by taxonomy, at its core, apachesolr is a search module and so if someone just wanted it so that they could have a fast, powerful search, but didn't care to include facets, they shouldn't be forced to add that dependency. I'm not as familiar with the D7 version, but I have worked extensively with the D6 version and I think it would make the most sense for there to be an apachesolr_taxonomy module which can add in those pieces of functionality as needed. My 2 cents, FWIW.

Also, I was working on writing an install profile to facilitate the process of rolling out several dozen sites. I would love to hear people's thoughts on whether this is an issue with core or just with apachesolr. If it is an issue with core, then I will likely need to change my plan for getting these sites rolled out. Thanks!

Sean

Changing the status of this back to what it was before it was set to closed, since "Reviewed and tested by the community" doesn't make any sense.

Also, for anyone who has bumped into this issue, I am using a work-around to get the apachesolr modules enabled using and install profile. I have added the following lines of code to the bottom of my profile's .install file, inside the myprofile_install() function:

// Work-around to deal with apachesolr dependency bug
// See issue: http://drupal.org/node/1410256
$apachesolr_modules = array('apachesolr', 'apachesolr_search');
module_enable($apachesolr_modules);

This seems to work because the other modules that it is dependent on have already been enabled. This is not, of course, a long-term solution, but it did fix it for me.

What are the next steps here? I'm very unclear what needs to happen now

@nick_vh - just to be clear, with my last post I was doing two things: 1.) Setting the status back to needs work as it had been set to closed and then rtbc even though the patch in #1410256-10: apachesolr_hook_info() calls entity_get_info() which can throw an error when installing using a profile. doesn't appear to work, or at least hasn't been given the thumbs up by anyone (it didn't work for me). 2.) I provided a work-around for people that need to enable apachesolr using an install profile.

To the best of my knowledge, what is necessary is the rest of the discussion about how best to deal with this issue and whether or not taxonomy should be considered a dependency of apachesolr. I don't think the patch above is a good long-term solution, personally.

I agree and disagree with @pyrello,

I also do not think that #10 is not a good long term solution, however for the people who need to install apachesolr as a part of an install profile, currently it is broken. Please see my comment at #14.

Having to manually call apachesolr to install itself where there is a perfectly good .info file for the install profile makes no sense, and seems like a far larger hack than #10 ever was.

So in summary, my suggestion is to:

1. Commit #10 and close this issue
2. Open new issue that deals with @pyrello suggestion of refactoring the taxonomy integration to potentially make it into a sub module that is optional (and dependent on taxonomy)

To be clear, I am not advocating the approach of having to install apachesolr manually. I posted that as a solution because the patch in #1410256-10: apachesolr_hook_info() calls entity_get_info() which can throw an error when installing using a profile. did not work for me. All that happened when I applied it was that I got a different dependency error. The work-around I posted is only meant as a temporary solution.

Just to comment that I don't think this error is isolated to apachesolar in install profiles. I am getting the same behaviour in my custom module - In my module I create some taxonomies and when I try and have this done on install via a profile I lose the taxonomy tables.

If I then put a dependency on taxonomy in the module (despite it being listed in my profile.info) I then get an issue with the RDF mappings module.

Remove reference to my home folder!

Please note that this can be problematic after any cache clear, too ...