Proof of concept override catalog_item

I guess this is related to this comment: https://drupal.org/node/2063587#comment-7755701

It sounds like if our fields are in a Feature, and DKAN wants to use Features for their own versions of those fields, Features Override may be the simplest way. I'll give it a shot.

Thanks for working on this. I don't think this project has much utility if this can't be figured out and documented. It is not just for DKAN but for any adopter of this either in a distro or a site. Almost everyone is going to want to change the fields from text fields to something more utilitarian like an entity reference to existing content or a use a link field to link to an external source.

Features Override does work, in that it stops the Feature from showing as "overridden". It seems a little cumbersome though if every site is going to need change these fields. Though I guess some site admins won't care if the Feature shows as overridden? (so they can just make changes as they see fit)

This patch, if enabled, changes the "Frequency" field to radio buttons instead of a select list. (not that we want that change, just a proof of concept)

coolio. i really want this to work. there are many admins that won't and shouldn't care about the features override state. but large builds need this ability. i wonder how scalable this is for larger instances.

About a year ago I tried Features Override and ran into problems when the overridden Feature changed, which would cause everything to appear overridden. I have to say that Features Override appears to be much more robust now. One thing I tried:
-disable the override Feature, make a different edit to the same component that was overridden, features-update the overridden Feature, re-enable the override Feature. The end result was that the component remained at the state specified in the override Feature, and nothing show up as "overridden". In other words if you override a component, even if the original Feature changes the configuration of that component, your version will continue to have priority, and there are no conflicts or "overridden" status, which is good.

One bit of weirdness happens if you have the override Feature enabled, and then you make a change to the overridden component, and then you do a features-update on the original (overridden) Feature. What appears to happen in that case is that the overridden Feature is updated to include all of the changes made by the override Feature, and both still appear as "overridden". This is not that bad though, if you're overriding the original Feature, you would never have a reason to do a features-update on it. So this would just be a case of user error. But if it does happen, you're kind of screwed and will need to re-download the original Feature again to fix the code.

I like the fact that in Features Override you can simply disable the override Feature and all of the changes disappear. Enable it, and they're back again. Very intuitive. I have no idea how well it scales though, as the number of overrides grows.

Almost everyone is going to want to change the fields from text fields to something more utilitarian like an entity reference to existing content

As I understand it (and please correct me if I'm wrong) even with Features Override you're not going to be able to accomplish this without data loss. Since you cannot change a field's type after it's created, your only option would be to delete the field (and its data) and create a new field of the desired type with the same name. This is probably fine if you do the override before you've populated your content, but after that...

On another note, what are the next steps for this ticket? It seems to me this is a largely dead end path.

As I understand it (and please correct me if I'm wrong) even with Features Override you're not going to be able to accomplish this without data loss.

If you hadn't created any content this wouldn't be an issue, correct? So if we want to build off of this for DKAN or some of the work you will be doing at Acquia or Phase2 etc Feeds Override would work as long as you hadn't created the content? I'll test this out myself soon.

Correct, acouch. This should only be a problem if you've already created content. Care should also be taken with the catalog node created by the install of opendata_content.