For some reason, my order entity metadata is being duplicated, resulting in array type values instead of strings (which in turn causes WSODs when entity_metadata_list_extract_type() hits these properties). Here's the resulting property array for order_id, and the same holds true for order_number.

                    [order_id] => Array
                        (
                            [label] => Array
                                (
                                    [0] => Order ID
                                    [1] => Order ID
                                )

                            [description] => Array
                                (
                                    [0] => The internal numeric ID of the order.
                                    [1] => The unique ID of the order.
                                )

                            [type] => Array
                                (
                                    [0] => integer
                                    [1] => integer
                                )

                            [query callback] => entity_metadata_table_query
                        )

The definition in commerce_order.info.inc is:

  $properties['order_id'] = array(
    'label' => t('Order ID'),
    'description' => t('The internal numeric ID of the order.'),
    'type' => 'integer',
  );

However, I also noticed in the dump that the full schema is being converted to entity metadata properties for things I haven't defined yet in my .info.inc. What's interesting, though, is that this same duplication problem isn't affecting uid which is also defined in my .info.inc.

Any leads?

CommentFileSizeAuthor
#3 commerce_fix.patch765 bytesfago
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

So, I see where in entity.module a schema is converted into entity metadata, but I don't understand why this is only resulting in duplicate data for commerce_order and nothing else. :-/

The only difference I can think of is Order is the only entity I have that does not use bundles.

Also, I noticed EntityDefaultMetadataController::entityPropertyInfo() doesn't make any accommodation for the revision_id in the entity keys array.

fago’s picture

Project: Entity API » Commerce Core
Component: Metadata integration » Order
Category: support » bug
Status: Active » Needs review

I had a short look at your code and I think the problem is that you accidentally made use of entity CRUD API by inheriting from its controller. As a consequence the entity API did generate metadata for you, what conflicted with your own provided metadata.

Attached patch for DC should fix the problem.

Not directly related, but the entity API might help you to save quite some code as it automatically generates Rules integration for the entities now - and as you have noted, helps with the metadata too. It does not yet support revisions though, but as this is currently a missing link I'd be happy to work with you on adding that if you like.

fago’s picture

FileSize
765 bytes
rszrama’s picture

Ahh, funny. I really wonder how that snuck in there... I'm guessing someone made the change in a patch and I didn't see it come through. And you're right - I think it would be wise to revamp the way we're taking advantage of Entity. When we first started, I went for minimal integration as I was in build mode and had my hands full enough trying to learn D7. Now having roughed out the entities, it's definitely time for some optimizing. It would be nice for me not to have to maintain some of this code... : D

I presume if we do change we would still require the .info.inc files but just wouldn't define properties that already exist in the schema (except for revision IDs)? Are there any other concerns we should be aware of? Would we even be able to use any methods from the Entity CRUD controllers or still need to keep our own (esp. for entities w/ revisions)?

rszrama’s picture

Status: Needs review » Fixed

Oh, and patch fixes the problem. I am having another issue with inactive Rule configurations not showing up all of a sudden, but I'll keep trying to troubleshoot that and post a separate issue if I just can't get it. If you know of anything in the data structure or API that might've changed causing this, lemme know. ; )

fago’s picture

ad #4:
>I presume if we do change we would still require the .info.inc files but just wouldn't define properties that already exist in the schema (except for revision IDs)?

Exactly, but probably you'll need to tweak the definitions for the generated ones too. So perhaps better just override the generated info totally with yours which is already fine.

>Are there any other concerns we should be aware of? Would we even be able to use any methods from the Entity CRUD controllers or still need to keep our own (esp. for entities w/ revisions)?

You can implement your own CRUD stuff, you just have to follow the interface to use save(), delete(), .. The controller doesn't support revisions yet, so you could just add that on top of it or bake revision support into the entity API controller.. :)

ad #5:
hm, unfortunately no. I haven't done much changes to rules at all recently, maybe something in core changed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.