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

[Mukesh Agarwal]

@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 <simon at hobbs.id.au> 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 <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.
> >
>



-- 
Cheers,
Mukesh Agarwal
________________________________
Innoraft Solutions <http://www.innoraft.com>  || +91 8017220799
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20111020/604b962d/attachment.html