This may or may not happen, but this would be really nice to have in multigroups.

Actually, CCK for D6 implements different storage methods for fields, depending on several factors. We have per content type table, and per field table. The later is used whenever a field is shared between several content types, or when more than 1 value is allowed for a field, in which case a new column is added to the primary key, the delta.

Well, maybe it is not so complex to tweak the current algorithm to add yet another storage method that assigns a per multigroup table to fields in multigroups.

Comments

Related support request: #528378: Multigroup Performance

If this will be implemented, it will make Flexifield module obsolete. Currently Flexifield is better in terms of multiple values child field support.

This is a great idea!

subscribing

Forget what I said in #2. Flexifield is almost abandoned and not really usable. Efforts must be aimed towards this feature so multiple field value inside multigroup row becomes possible.

Subscribing.

Anyone consider 1 table per storage type: int, varchar, text, blob? As I see it having 30 tables for 30 CCK fields can be overkill. This standardization might make the separation between data and configuration more clean as well. Thoughts on this?

subscribing...

subscribing, as this could help to work together Hierarchical Select and Multigroup

Subscribing.

The question is how this would ever be ported into D7 when we already have a somewhat murky upgrade path. In D7, every field is in its own table always. I am not sure what markus_petrux was envisioning for this in D6, let alone what that would have to do to migrate to D7.

@markus_petrux, any thoughts?

The idea behind this issue, considerations related to D7 migration path aside, was that since all fields in a multigroup share the "number of repeats" attribute, they could be stored in the same table (key would include the delta, just like per field storage for multiple valued fields). A single table for the whole multigroup would help enhance performance, and also Views integration because queries that need synchronization of deltas would involve a single table added to the view joins.

Though I have never had the time to finish this, and we were solving the performance issues using Views caching, which is something that was possible in the meantime.

Subscribing

@markus_petrux:
I am working on a project which need a common database model: 1 table for all multigroup fields (as I described here: http://drupal.org/node/690140#comment-3541778). My project is using Drupal and a desktop app using Delphi 7 (that's why we really need multigroup with 200 fields uses 1 table rather than 200 tables).

Also, you mention we can leave dirty LEFT JOIN vid, nid and delta if we use 1 table for multigroup.

Currently I still try to understand 6.x-3.x-dev for 1 multigroup table, but I will fix the "forgetting arguments when add another value" issue first. Please attach any code you may have so we can accelerate this.

IMPORTANT:
------------
Master table named as: content_type_typename
what is the name format for 1 table of multigroup? Do you suggest content_type_typename_detail or what?

I'm hoping this is still in progress. Will this mean that Token will be better able to recognize multigroup content?

Status:Active» Postponed (maintainer needs more info)

This is unlikely to happen now that D7 is out. We are mostly getting Multigroup as functional as possible, not trying to add new features.

Basically, unless someone steps up with a working, tested, patch, this won't happen.

Status:Postponed (maintainer needs more info)» Postponed

Wrong status.

Subscribing.