Hi,

I've added a new vocabulary and term reference field on a content type. I can't select the vocabulary, the select list looks disabled with the first vocabulary selected (first vocabulary in the vocabulary list ordered alphabetically).

The select list when adding a new node is empty.

Using latest dev version of mongodb module and drupal 7.2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ronsnow’s picture

Issue tags: +taxonomy, +vocabulary
FileSize
27.09 KB

...operator error....

lurkingbeast’s picture

I see this too, it has something to do with field_has_data function. I'm not sure whether it's mongodb field storage module which should return something else on this query or what, I didn't have time to look into this further.

I resorted to an annoying hack, when I want to add or edit a taxonomy term reference field, I edit the modules/field_ui/field_ui.admin.inc in two places:

// $has_data = field_has_data($field);
$has_data = FALSE;

and then after choosing the vocabulary I revert the code.

Would be great if someone would point in the right direction where the problem lies.

MiSc’s picture

Priority: Normal » Critical

This is still an issue, I changed status to critical - because this issue make mongodb not usable for storing taxomomy entities.

lurkingbeast’s picture

On a related note, I made a small change to core taxonomy.module to allow taxonomy index to be updated correctly when using mongodb for taxonomy entities (just quick advice, no patch):
in
function taxonomy_field_insert($entity_type, $entity, $field, $instance, $langcode, &$items) {
and
function taxonomy_field_update($entity_type, $entity, $field, $instance, $langcode, &$items) {

replace first line with

if (variable_get('taxonomy_maintain_index_table', TRUE) && ($field['storage']['type'] == 'field_sql_storage' || $field['storage']['type'] == 'mongodb_field_storage') && $entity_type == 'node') {
MiSc’s picture

Issue tags: -taxonomy, -vocabulary
FileSize
1.75 KB

Good point lurkingbeast, just stumbled over that problem. Added patch for your fix. By the way - do you store the index in mysql or mongodb?

MiSc’s picture

The path was not generic, adding a new.

MiSc’s picture

Sorry, again, hopefulle this one would work more correct

lurkingbeast’s picture

In my case the index is stored in mysql.

drupik’s picture

What about Drupal 7.12?
Based on this patch, I changed line 1773 from taxonomy.module
if ($field['module'] == 'taxonomy' && $field['storage']['type'] == 'field_sql_storage') {

to
if ($field['module'] == 'taxonomy' && $field['storage']['type'] == 'field_sql_storage' || $field['storage']['type'] == 'mongodb_field_storage') {

but error in SQL

Notice: Undefined index: tid w taxonomy_build_node_index() (line 1788    ....taxonomy.module).
Notice: Undefined index: tid w taxonomy_build_node_index() (line 1788    ....taxonomy.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'tid' cannot be null: INSERT INTO {taxonomy_index} (nid, tid, sticky, created) 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] => 101 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => 1330886392 [:db_insert_placeholder_4] => 101 [:db_insert_placeholder_5] => 21 [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 1330886392 ) in taxonomy_build_node_index() (line 1805 in   .....taxonomy.module).

So I changed also line 1788:
$tid_all[$item['tid']] = $item['tid'];
to
$tid_all[$item['tid']->tid] = $item['tid'];
Now terms saving, but still have error:

    Notice: Undefined index: tid w taxonomy_build_node_index() (liniea 1788 ....taxonomy.module).
    Notice: Trying to get property of non-object w taxonomy_build_node_index() (line 1788 ....taxonomy.module).
    Notice: Undefined index: tid w taxonomy_build_node_index() (liniea 1788 ....taxonomy.module).
    Notice: Trying to get property of non-object w taxonomy_build_node_index() (line 1788 ....taxonomy.module).
drupik’s picture

Take taxonomy.module from D7.10, patched and voila :)

MiSc’s picture

Hm, I do not think that you should hack so much that you use old versions of modules ;-). We have to look into this issue.

kalmarzs’s picture

Unfortunately I have the latest modules and core, however I have the same issue. I will try the patch and report back with the results.

lurkingbeast’s picture

Seems that for 7.12 they have reorganized the taxonomy code a bit, I did this:

In function taxonomy_build_node_index($node)

if ($field['module'] == 'taxonomy' && ($field['storage']['type'] == 'field_sql_storage' || $field['storage']['type'] == 'mongodb_field_storage')) {

Appears to work. It's good to see work going on with this module.

MiSc’s picture

Patch for solution for d7 in comment #13 attached

MiSc’s picture

Status: Active » Needs review
MiSc’s picture

I started work on putting the taxonomy_build_node_index stuff inside mongodb_module so we do not have to patch a core module when we want to have that with the Mongodb backend - a couple of questions:

* Should this index be stored in Mysql or Mongodb?
* Should it be in the field_storage_module, seperate or somewhere else?

For the original issue here, solved in comment #2 with patch of core module, I will start work to try to get this inside the Mongodb module also.

MiSc’s picture

First patch of implementing index in the Mongodb module - this is stored in Mysql.

Janne Salo’s picture

Status: Needs review » Needs work

I've been using the taxonomy index patch (in #17) for a while now. It seems to work ok for new nodes, but node updates delete data from the taxonomy_index table. This is because taxonomy.module runs taxonomy_delete_node_index() and taxonomy_build_node_index() on node updates. The former (obviously succeeds) but the latter doesn't, since the storage type of my node's field isn't field_sql_storage. Now, this is exactly the problem the above patch is for, but it falls a bit short since taxonomy.module's node_update hook is run after mongodb_field_storage's node_update. Which is inconvenient because it deletes the rows mongodb_field_storage just inserted but doesn't insert anything on its own (because of the storage type check).

An easy solution would be to just increase mongodb_field_storage's weight by 1.

a) Do you feel this is the best possible solution (or at least good enough)?
b) If yes, should we automatically increase the weight of the module in, say, hook_install() or hook_enable()?

Other than this, the patch seems to work just fine.

MiSc’s picture

For the original issue raised in this issue, solution is committed to latest dev, see #1547198: field_has_data() will always return TRUE.

MiSc’s picture

Title: Vocabulary selection not possible » Allow taxonomy index to be updated correctly when using mongodb

Renamed, because of two different issues raised here, the first one, is solved, see comment #19, the second one (comment #4 - latest patch in comment #17) is still waiting to be fixed..

firebird’s picture

Janne, the current best practices call for the use of hook_module_implements_alter() instead of juggling weights. See http://api.drupal.org/api/drupal/modules!system!system.api.php/function/... .

sarhugo’s picture

Status: Needs work » Needs review
FileSize
4.17 KB

Modified version of #17 implementing hook_module_implements_alter(). Also removed the deletion from taxonomy_index table. It should be made by the taxonomy module, so if there are some fields with sql storage then these are preserved.

sarhugo’s picture

Sorry, just found a bug at the previous patch. I removed the hook_node_delete implementation without removing from the hook_module_implements_alter.
Attached a fixed version

MiSc’s picture

Status: Needs review » Needs work

Thanks @sarhugo, patch works as it should, but the coding standards are not followed, could you please update the patch with the current coding standards?

sarhugo’s picture

Status: Needs work » Needs review
FileSize
4.17 KB

Fixed the wrong indenting

chx’s picture

I need to know why this is critical and why do we even want to populate an SQL table when all work is done to move away from any SQL storage? Where is this table used that you see it as useful? Please consider the entity controller code lying around which marks my intention to entirely remove entities from SQL.

MiSc’s picture

Priority: Critical » Normal

I do not think this is critical (but the possibility to choose a vocabulary was), but this just make the core indexing of taxonomy terms work - my first patch suggestion is just a quick fix for that. I mark this as normal.

fgm’s picture

@chx: The patch itself may or may not be the best implementation, but filling "something like" {taxonomy_index} enables taxonomy pages to point back to any nodes containing a term reference to the chosen term, whichever the field. This is something that is not implemented in core is taxonomy_index, nor with entityreference pages, with which any backlink from a taxonomy term is via a specific field, not across all fields and instances pointing to that term.

So there /is/ a use case. But there are other ways to implement it.

chx’s picture

What about providing the taxonomy pages via efq_views? I suspect it's easy by now.

MiSc’s picture

I think it should be important to have so much functionality as possible from core that works the same when we have mongodb field storage, so modules that uses the same functionality does not brake when it uses another backend.

fgm’s picture

Maybe I'm missing something, but EFQ (and hence) EFQ_Views will still need manual selection of the fields used to build the references, or code to build the view dynamically based on current field_info_fields(), so this introduces both more code to build the EFQ and a dependency on EFQ_Views. Or maybe EFQ_Views could have a handler to agregate term references across field instances. Just thinking loud.

chx’s picture

We are getting to #31 slowly , I pushed taxonomy term reference field filters to efq_views just now.

chx’s picture

Is it a valid use case to have several term reference fields using the same vocab? The typical pattern seems to be $field_name = 'taxonomy_' . $vocabulary->machine_name; and then instantiate that so I truly wonder whether once the argument (contextual filter) handler is added to efq_views this could be closed down.

fgm’s picture

Typically, many sites will prefer to use multiple fields with almost identical definitions instead of creating multiples instances of a given field, so this will likely also apply to taxonomy term references.

chx’s picture

Why on earth would anyone do that? I am genuinely curious.

MiSc’s picture

@chx: I have to agree with fgm, I have seen that in many places.

fgm’s picture

One problem with instances is views integration, which is typically limited to per-field settings, not per-instance. This is something we run into constantly with entityreference plugins.

Janne Salo’s picture

I don't know if the use of the patch in #25 is encouraged or not, but I need it and you can't patch the latest dev version (Jul 27) with it, so I created a new version of the patch in case someone else needs it too. It's the exact same code, but it should work with the current dev version.

chx’s picture

If you would reroll it with a mongodb collection insert I would consider but db_insert is a flat-out no.

mgifford’s picture

I might be able to re-roll this, but need to get a bit more direction @chx as to what you're needing to be improved in this patch.

We applied MongoDB and had a bunch of problems with the taxonomy and are still trying to figure out what the problem was.

chx’s picture

What I meant is that if you want to keep the taxonomy-node denormalized data around, do it in MongoDB not in SQL.

Summit’s picture

Hi, referring to this issue about taxonomy, can I now use Taxonomy_menu etc...taxonomy driven modules with storing the taxonomy entities in Mongo? If you want me to place another issue for this, sorry then.

greetings,
Martijn

marcingy’s picture

Status: Needs review » Needs work

As per #41 the mongodb module should be doing no operations on MySQL.

protools’s picture

incorrect work with taxonomy breaks all reasons to use mongo

sunnykasera3107’s picture

Issue summary: View changes

I was also facing this issue and just added a hack using custom module. I check for data exist for the field in mongodb on form alter of field settings. I am sure it is not right way but it works for me.

Here is code

function custom_code_form_field_ui_field_settings_form_alter(&$form, &$form_state){
  $field_name = $form['field']['field_name']['#value'];
  $entity_type = $form['#entity_type'];
  $mongodata = mongodb_collection('fields_current', $entity_type)->find(array($field_name => array('$exists' => TRUE)))->limit(1)->count(TRUE);
  if(!$mongodata){
    $form['field']['settings']['allowed_values'][0]['vocabulary']['#disabled'] = 0;
  }
}