The new D7 version of Node Gallery is a great start! The new features and architecture look appealing also. Kudos all around.

One thing I've experienced with the new D7 version is that for every Node Gallery Relationship Type I add (under admin/config/content/node-gallery), it automatically generates a field with the name field_node_gallery_ref_x (where x is the ID of the relationship). When putting images into certain galleries though, the associated tables for these fields don't appear to be used.

These tables always seem to be empty:

field_data_node_gallery_ref_1
field_revision_node_gallery_ref_1

Instead all the data is stored into:

node_gallery_relationship

This table seems to be used for all relationship type fields.

Is this a correct assessment? And is there some way we could remove these default tables that don't get used?

Comments

zengenuity’s picture

zengenuity CreditAttribution: zengenuity commented

Yes, you're right. I don't know a way to get rid of them right now. Is there some way to hook into the field storage engine to tell it you don't want this field stored with SQL? EntityReference lets me clear the data so it doesn't get double-stored, but I haven't seen a way to get rid of the table altogether.

BTW, for some background: I took this architecture style, using EntityReference, from OG 7.2. OG has fundamentally the same requirement we do. This group of nodes are all related to a that other node. Amitaibu is a lot smarter than me about this, so I figured it was best to copy his approach. (At least from the 2.x version...much better than 1.x.) The one major downside I didn't realize until I got deep into coding it is that EntityReference fields cannot have different target bundles per instance. That setting can only be done at the field level. So, every relationship type has to have a different field. That's why you end up with node_gallery_ref_n as the field names. This is true of OG, as well, though it's probably rarer to need more than the default membership type. I decided to stick with this approach, despite the extra fields, because I think now that Node Gallery supports using File Entity to theme the uploads, most sites will only ever need one relationship type.

OG 7.2 also adds extra empty tables to the DB, so they haven't solved this issue either.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Priority: Normal » Minor

Huh weird. I'm pretty sure both Barry Jaspen and yched have told me that each individual field is allowed to defined *custom* table storage per field. Making so that Field API itself would do the saving for you into a custom table of your own choosing. I raised a huge stink about the god-awful "each field gets its own table" approach during the development of D7, which led Barry to prove the D6 approach was still possible if you really wanted it: http://drupal.org/project/pbs

However as you might expect, no one could possible assume an efficient database storage so everything was written directly against the default SQL storage (or abstracted the Entity Field Query, which removes any database-table level optimization through its approach). So in *theory* this is at least possible, but I have yet to see it in actual practice.

In any case, I just wanted to make sure I didn't need to put stuff into these tables as part of #1792192: Upgrade path from Drupal 6 (3.x) to Drupal 7 (1.x) version. I'll keep investigating this a bit and see if it's possible to get Field API to be a little smarter about this.