Support Revisions in ECK

After talking with EclipseGc I think that it would be reasonable to hold all the revisions for all eck created entities in one table. ECK uses the same simple schema for all created entities, so I think that this could be reasonable, and it would keep us from junking up the database with more tables. Does anybody see any issues with this?

There has been work done on revisions for entity API here #996696: Support revisions in Entity API

Since this modue is using entity API I would think it should build on top of that.

The patch is in a usable state but fago has not reviewed it in a while.
It would be good to get more people testing that patch so maybe this module can be used to test it some more.

The patch in #996696: Support revisions in Entity API has been committed now.

see #1031010: Support revisions for field collections

Any news?

Great, @fmizzell. If you need help, tell us.

Is it possible to get an update on the status of this please?

I'm working on something and if everything goes well, by next week we should have something up for testing.

Hi,

In order to get this revision up and running the following patch needs to get committed then install ECK Revision.

ECK Revison
https://www.drupal.org/project/eck_revision

Feel free to test and report issues.

re #13, does that mean you need that patch plus that module or just the patch?

Shouldn't it all be in this module?

It needs that patch plus the module.

Seems like this should all be in the same module, would it be feasible to make a patch for this module based on your module?

The maintainer says they will accept a patch for the 3.x branch.

Aside from Drupal core entities (like users, which require a secondary module to add revisioning), all entity related modules I know of have revision support in the main module.
It's pretty core functionality.

--

eck_revision has been patched & committed to match eck.

I got some nasty fatal error message on the latest dev commit from yesterday. I think it was related to this patch.
Fatal error: Cannot use object of type EntityType as array in contrib/ctools/includes/export.inc on line 1058

Just thought I'd drop a line, I'll investigate further later.

Sorry #21 completely unrelated, ignore me...

Inside eck_schema_alter(&$schema) it seems to be now merging on the EntityType object.

So cancel that ignore me in #22.

Though this may be a new bug, I only saw it after this patch. Seems to be the fault of
eck_property_behavior_invoke_plugin_alter() or maybe more likely eck_schema_alter().

From what I gather, $entity_type_shema maybe should be merging the schema result?

if ($entity_type_schema) {
        $schema = array_merge($schema, $entity_type_schema);
      }

to something like

    if (isset($entity_type_schema['schema'])) {
        $schema = array_merge($schema, $entity_type_schema['schema']);
      }

OR eck_property_behavior_invoke_plugin_alter() is not the right function for the job of letting the properties modify the schema?

Feel free to boot me to a new issue...

Here is that as a patch, it fixes the problem, though it may be best to get a maintainer review.

#2300901: ECK's schema alter behavior hook has been modified patch has been commited.

ECK_revision should be working just fine with the latest ECK version.

Thanks that's saves the fatal and is a bit better than what I had!

I noticed you put in array_key_exists, and I just learned about that a few months back but I think you have it backwards. The article that was referenced to me last time I brought it up was that array_key_exists is needed (I always used on isset() in most of my usecases)

http://www.zomeoff.com/php-fast-way-to-determine-a-key-elements-existanc...

So because isset() calls are ~2.5 times faster you should lead with isset() and use PHP's conditional shortcuts to avoid the extra check for NULL values that array_key_exists catches.

And just one little nitpicky tip on coding standards, depending on your editor of choice, you can turn on a column ruler at 80 characters to help spot when you should break a comment line. And also most editors have a nice little trim trailing whitespace on save, which is nice to not have to think about those things as much.

Simply an update regarding ECK Revision. I've commited a new version that adds the revisions tab in order to manipulate the revisions of an entity.

Any testing would be great :)

@fmizzell I noticed, thank you:) I opened a new issue to tackle a bit more that I was mentioning in #28

#2309321: Optimize code by using empty or isset instead of array_key_exists

Since the question in #16 was not answered, am I right in assuming that this will remain in a separate module for the 2.x branch and then be within this module for the 3.x branch?

No worries, thanks for the clarification.

Hello

3.x branch is now unsupported.
#2495527: 3.x Roadmap: Unsupported, do NOT use

Can we get this functionality in ECK 2.x?
#2727433: Merge to ECK
eck_revision

I understood that this issue was once closed since all the tasks were completed.

What are the remaining tasks in this thread? All the commits seems to be included in the version 2.x... Maybe, is to merge ECK Revision module expected to be handled in this thread?

Last patch is 7 years ago. I recommend to mark this as duplicate to merge forces and efforts in the 8.x issue regarding revision support and go from there to discuss a possible backport if still required. #2788507: Add revision support