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 bsenftner@earthlink.net 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 <mukesh.agarwal17@gmail.com> 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 <simon@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@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 || +91 8017220799