A little background: we play tug of war with the number of fields (fields not instances) ever growing on our site and the performance of having those fields specifically in the checkout process for a commerce order. I was curious if defining these field within the specific .tpl file would 1) Alievate this problem with drupal and the fields vs performance tradeoff, and more importantly 2) Not break the drupal commerce order.

Such a field would be added to the order array as $order->my_field. I guess I am asking how commerce order would react and if the data would still be saved properly, such that the field does not possess its own tables and is almost invisible to the overarching drupal.

Comments

rszrama’s picture

rszrama commented
Status: Active » Closed (fixed)

You really shouldn't beusing any non-Field API field on an entity; besides the saving / loading / display code you'd have to invent yourself, you're also missing out on the Entity API / Rules / Views integration. It just doesn't make sense.

jmomandown’s picture

jmomandown commented

I can't think of any other way to circumvent the performance derogation, which seems to triple within commerce. It takes about 15 seconds to submit an order form in commerce (granted an order form has about 75 fields associated with it in addition to the defaults). I do see what you are getting at though.

For kicks or anyone that may stumble upon the thread, I did try this and it will cause an error when submitting the order if the field is not a part of the order entity itself.

rszrama’s picture

rszrama commented

I don't get why you have 75 fields, honestly. Maybe you're just using the field data model incorrectly? If you want improved performance and you don't need the advantages of fields I outlined above, there's no reason you couldn't create a custom entity type and embed that entity form in a custom checkout pane or something. The custom entity type could simply write all this information to a single custom table (or perhaps a few different tables depending on the type of data you're collecting).

Field operations are slow because updates are treated as deletes / reinserts. Perhaps you just need to mitigate how often this data is actually being inserted / updated some other way than having every field show up on one giant form (which can't be great for conversion anyways).

jmomandown’s picture

jmomandown commented

The number of fields are because there is a dynamic requirement for every form that is not standard coming in. Thus every form embedded in the order requires a different set of "fields" to take data. The derogation of performance within commerce order trying to deal with these does not come from the 75 embedded fields, it comes from all the fields within the mysql tables which drupal and commerce are pulling the field info on (as drupal to my understanding, pulls the information for all fields).

I actually thought of using entities for a bit as a work around for commerce order, the issue was that that entity would still have to be fieldable to account for the dynamic form fields expected to be pulled in, thus we end up with the same fields issues within the commerce order form. Perhaps I have a improper understanding of the way drupal and commerce work together in this regard, but that is my logic.

jmomandown’s picture

jmomandown commented

@rszrama: Thanks as always for taking the time to give informative and helpful responses in this thread and many others.

I do want to say that I have begun transferring the commerce specific fields, including those discussed to a MongoDB, which seems to help quite a bit since Mongo doesn't really use a single table for each field in the way that it stores things. This seems to have helped quite a bit on the commerce checkout/order side of things.

Also for further information should anyone run across the thread, I think the conversation over at: http://drupal.org/node/1040790#comment-6904506 may also be a possible solution.

rszrama’s picture

rszrama commented

Ahh, great. Your thread actually got me to thinking about Mongo and Price fields, too. Right now we have this issue where valuable data is tucked away inside data columns on price fields - specifically the components. If we had price field data in a document-oriented database, we could actually generate meaningful reports based on that data. Wishful thinking perhaps, but something to consider for D8.

jmomandown’s picture

jmomandown commented

rszrama I think that would be a great move and I have also had frustrations with the price fields prior. I will caution you though that since commerce relies heavily on views, it would be a rather large undertaking. Views and Mongo don't work kindly with one another at this point.

Guess you may have to keep duplicate column variables for the time being to have that information readily available :(