[development] Drupal 7 CCK fields in separate tables - why?

[Simon Hobbs]

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 <mukesh.agarwal17 at gmail.com> 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.
>