Bean + UUID / Deploy

This might be a solution for you: #1849668: Add support for Bean exporting (deployable bean instances).

The link brantwynn points to a patch for module UUID_features that fixes the Bean UUID deployment.

So I didn't have the issues that the OP had here, Bean and deploy are working well for me.

But that said, sylus is correct, those functions are not necessary and probably could cause problems in certain instances. In uuid during entity_uuid_save() there is a call to entity_make_entity_local(). During this function, it automatically finds the id field of the entity (in this case the 'bid' field) and runs entity_get_id_by_uuid for the id field using the value in the uuid field. This has the effect of changing the 'bid' value to the proper local value that corresponds to the uuid. That all happens for free without needing to invoke the hook_entity_uuid_load or the hook_entity_uuid_presave.

This is good to go.

marking as needs review to get the test to trigger

Thanks!

https://drupal.org/commitlog/commit/22232/a8c8cd7596173fb781b6593c0d6be7...

*EDIT*
We're getting an issue trying to deploy bean deploy a translated bean using sqlsrv and bean_uuid.

here's the error that shows up on the destination side: "Undefined property: Bean::$bid in bean_access()"

Deploy is set up and working for us deploying nodes, taxonomy and files , but

At this point I'm not sure if it's best to fix it as a patch to bean_uuid or else to make changes to ths sqlsrv driver it'self is not yet known where the best place to fix this is.

At this point I'm not looking for a graceful fix, I'm looking for any possible fix/workaround using when sqlsrv.

As a bounty, if someone can help fix this , I will donate a small amount of money to the charity of their choice.

*EDIT* see my followup comment

After debugging and re-testing we were able to get bean deployment to work. Our problems were most likely related to issues related to having cloned our sites prior to enabling deployment and some content existed in both sites.

I ran several tests, eventually just creating a few new beans and deploying new beans, by the 5th bean and 3rd try, it worked without errors, I'm thinking that things are getting into sync, I'll continue monitoring this, but looks like its working now.

we'll have to remove the content from destination and then re-deploy it , should be able to fix things like that, will involve some work though to verify any panel pages that had block content make sure the same blocks show up on the intended pages or re-add the blocks in, should take some work but doable cleanup (a few hours of work).

thanks again for the assistance and suggestions by Sylus and for his patches.

The Deploy issues we were facing was related to deploying newly created bean with one or more translations. In our case the fix for Deploying a newly created translated bean was to apply the patch in this related issue found in the 'bean' queue . This patch is now included in the wetkit distribution of Drupal.

I hope that the related patch upstream will be committed to the 'bean' module so that others deploying newly created translated entities of type bean will not have this issue.

Sincere thanks to Sylus for his invaluable help with testing and debugging and for locating the patch. Also, thanks to a.milkovsky for the patch. This allows us to use bean and deployment with bilingual/multilingual situations without having to resort to panels visibility rules and 'bean per language' , so now we have entity deploy for bean with translations.

Thanks very much. Not only does this work with our non-mainstream database abstraction layer but it works with mainstream Drupal 7.