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

Comments

Issue tags:+taxonomy, +vocabulary
StatusFileSize
new27.09 KB

...operator error....

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.

Priority:Normal» Critical

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

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') {

Issue tags:-taxonomy, -vocabulary
StatusFileSize
new1.75 KB
Test request sent.
[ View ]

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?

StatusFileSize
new1.73 KB
Test request sent.
[ View ]

The path was not generic, adding a new.

StatusFileSize
new1.72 KB
Test request sent.
[ View ]

Sorry, again, hopefulle this one would work more correct

In my case the index is stored in mysql.

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).

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

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.

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.

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.

StatusFileSize
new791 bytes
Test request sent.
[ View ]

Patch for solution for d7 in comment #13 attached

Status:Active» Needs review

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.

StatusFileSize
new3.23 KB
Test request sent.
[ View ]

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

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.

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

Title:Vocabulary selection not possibleAllow 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..

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/... .

Status:Needs work» Needs review
StatusFileSize
new4.17 KB
Test request sent.
[ View ]

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.

StatusFileSize
new4.16 KB
Test request sent.
[ View ]

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

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?

Status:Needs work» Needs review
StatusFileSize
new4.17 KB
Test request sent.
[ View ]

Fixed the wrong indenting

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.

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.

@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.

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

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.

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.

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

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.

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.

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

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

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.

StatusFileSize
new4.17 KB
Test request sent.
[ View ]

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.

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

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.

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

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

Status:Needs review» Needs work

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

incorrect work with taxonomy breaks all reasons to use mongo