Re: Drupal 7 CCK fields in separate tables - why?

I'm building a "cheezefield" module right now myself. 
Perhaps this is pure Frankenstein, or maybe it's good:

I have a complex content type managing a variable number of files, with variable attributes and properties for each file. Also this content type has references to other nodes of the same type. To implement, I created a fieldset holding all of these possible fields, and generated 10 of them in a loop. For the UI, they appear as needed via jquery, and js validation makes only the fields appear that correspond with a given file type. The module's DB presence is my one table for the additional content type, and for each of the datatypes in the fieldset I have a big varchar field holding a serialized keyed array of values entered by the user. It's really simple to just assign my data arrays to the node, at insert/update serialize them and at load unserialize to recover my keyed arrays.

I'm 75% of the way done with with after a day, expecting to wrap up today. Considering that serialize/unserialize can't be less performant than ooodles of DB calls, this looks like a winner to me...

Sincerely,
-Blake
[email protected]
www.BlakeSenftner.com
www.Droplabs.net
www.MissingUbercartManual.com

On Oct 20, 2011, at 1:29 AM, Simon Hobbs wrote:

> Coolio. Like I say, it might already exist, I'm going to have a closer
> look at the properties module myself. I had a situation where I was
> mapping Netsuite entities to content types and the fields tables were
> getting out of hand, IMO. I had content types with dozens of fields
> and to display the full content type with a view could feasibly break
> the 61 join limit of MySQL 5.x. You might never get there, but if you
> do you can bet it's late in the build and you will be crying into your
> free beer.
> 
> .s
> 
> On 20 October 2011 17:53, Mukesh Agarwal <[email protected]> wrote:
>> @Michael: thank you for the clear explanation. I'll sure try the module.
>> @Simon: In the current scenario of my application, I might end up building
>> the "cheesefields" module (wonder whether you add cheese to name your
>> modules :P) and then contributing it to the community.
>> On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <[email protected]> wrote:
>>> 
>>> Hey Mukesh
>>> 
>>> There is really nothing wrong with the approach in core, and making it
>>> generic. It fits a wide variety of use-cases.
>>> 
>>> But, sure, maybe we don't always want it that way. That's why Drupal
>>> is awesome. Entity API and other hooks.
>>> 
>>> I'm waiting/looking for a module (call it "cheesefields"):
>>> 1. Your DBA makes a pretty table.
>>> 2. You expose the info (via hook_schema) to drupal
>>> 3. You implement hook_cheesefields_info() and to say which field is
>>> the key and which entity type it maps to.
>>> 4. cheesefields then implements the entity api hooks based on our
>>> tables fields and their data types. We get widgets and everything,
>>> with the ability to do an alter on the autodetected widgets and
>>> specify alternative widgets.
>>> 
>>> To put it a different way, all your fields in one table is not
>>> different to a field module that defines multiple fields. We just need
>>> to expose it correctly.
>>> 
>>> Simon
>>> 
>>> PS. If you know of this cheesefields module please tell me.
>>> 
>>> 
>>> 
>>> 
>>> On 20 October 2011 17:11, Mukesh Agarwal <[email protected]>
>>> wrote:
>>>> Thank you Ernst for the advice.
>>>> I think we could have achieved different revisions for each field by
>>>> marking
>>>> a field in UI as something that requires revision which would mean only
>>>> those fields that require a different revision can do that. Same goes
>>>> for
>>>> translation. I think the entire field entities API is nice and makes
>>>> programmers life easier. But in trying to make things generic, we have
>>>> added
>>>> a lot of overhead on Drupal core - content management system.
>>>> Using MongoDb is a good option. I like the idea but since the support
>>>> system
>>>> for the same is not that strong, I'm sure clients will have a concern.
>>>> I'm not sure if I want to chuck Drupal as a solution to our problem.
>>>> Will
>>>> have to find different ways.
>>>> Not convinced with the separate fields idea though.
>>>> 
>> 
>> 
>> 
>> --
>> Cheers,
>> Mukesh Agarwal
>> ________________________________
>> Innoraft Solutions  || +91 8017220799
>>