silverstripe / silverstripe-versioned

Versioning for Silverstripe model
BSD 3-Clause "New" or "Revised" License
8 stars 36 forks source link

Version number for many-many-through "join" items doesn’t ever change #130

Closed kinglozzer closed 6 years ago

kinglozzer commented 6 years ago

Perhaps this is expected, just struck me as odd. Given the following versioned models:

I added a CheckboxSetField for linking them which works, but every record in the ProjectType_Versions table has the same Version number. For example, if I tick a “type” & publish, then untick & publish, then re-tick & publish the same “type”, there are 2 records in the versions table that are effectively identical:

screen shot 2018-03-05 at 17 03 47
tractorcow commented 6 years ago

I'll look into this and respond to it later.

tractorcow commented 6 years ago

If you aren't making changes to the relationship, and you save, and there are new rows created, it probably shouldn't create a new version just for draft.

However, if you publish a record it probably should create a new row. Except in your example above I don't see WasPublished set to 1, so I'm not sure what is going on specifically in your example.

What would concern me is that the ID column of ProjectType is incremented for each save; If you need to create a new record each save, instead of re-using existing mapping records, that may be a problem.

tractorcow commented 6 years ago

@kinglozzer please provide framework version, and either some example code and I'll reproduce it locally. Make sure you declare:

kinglozzer commented 6 years ago

Thanks @tractorcow, I’ve dumped the simplified models into a Github gist: https://gist.github.com/kinglozzer/17fd89233f5026011206de3319707966. composer show:

composer/ca-bundle                        1.1.0   Lets you find a path to t...
composer/installers                       v1.5.0  A multi-framework Compose...
embed/embed                               v3.3.1  PHP library to retrieve p...
guzzlehttp/psr7                           1.4.2   PSR-7 message implementat...
intervention/image                        2.4.1   Image handling and manipu...
league/flysystem                          1.0.43  Filesystem abstraction: M...
m1/env                                    2.1.0   Env is a lightweight libr...
marcj/topsort                             1.1.0   High-Performance TopSort/...
monolog/monolog                           1.23.0  Sends your logs to files,...
nikic/php-parser                          v3.1.5  A PHP parser written in PHP
paragonie/random_compat                   v2.0.11 PHP 5.x polyfill for rand...
psr/cache                                 1.0.1   Common interface for cach...
psr/container                             1.0.0   Common Container Interfac...
psr/http-message                          1.0.1   Common interface for HTTP...
psr/log                                   1.0.2   Common interface for logg...
psr/simple-cache                          1.0.1   Common interfaces for sim...
silverstripe/admin                        1.1.0   SilverStripe admin interface
silverstripe/asset-admin                  1.1.0   Asset management for the ...
silverstripe/assets                       1.1.0   SilverStripe Assets compo...
silverstripe/config                       1.0.4   SilverStripe configuratio...
silverstripe/framework                    4.1.0   The SilverStripe framework
silverstripe/graphql                      1.1.0   GraphQL server for Silver...
silverstripe/recipe-plugin                1.1.0   Helper plugin to install ...
silverstripe/vendor-plugin                1.3.1   Allows vendor modules to ...
silverstripe/versioned                    1.1.0   SilverStripe Versioned co...
silverware/datepicker                     1.0.0   SilverWare Datepicker Mod...
swiftmailer/swiftmailer                   v5.4.9  Swiftmailer, free feature...
symbiote/silverstripe-gridfieldextensions 3.1.1   A collection of useful gr...
symfony/cache                             v3.4.6  Symfony Cache component w...
symfony/config                            v3.4.6  Symfony Config Component
symfony/filesystem                        v3.4.6  Symfony Filesystem Component
symfony/finder                            v3.4.6  Symfony Finder Component
symfony/polyfill-apcu                     v1.7.0  Symfony polyfill backport...
symfony/polyfill-mbstring                 v1.7.0  Symfony polyfill for the ...
symfony/translation                       v2.8.36 Symfony Translation Compo...
symfony/yaml                              v3.4.6  Symfony Yaml Component
webonyx/graphql-php                       v0.8.0  A PHP port of GraphQL ref...

There’s no ownership set up between projects and project types, adding that didn’t seem to make any difference

tractorcow commented 6 years ago

Thanks I'll check it out now. ;)

tractorcow commented 6 years ago

Ok, I've done my research and I can resolve this with explanation for how this works;

Because the ProjectType mapping dataobject has NO extra fields (only parent / child relations) there will never be the need to create a "new" version of an existing record.

When you unassign a many_many and re-assign it, you aren't creating a new version of the same relation, you are deleting that record, and creating a brand new record for that relation. Two record creations (different RecordID) but each is only ever created and never modified (unless it's deleted). These versions never get a chance to create Version 2, because their values never change.

If you look at your example, the records aren't identical, they have two different RecordIDs. This would be synonymous with me creating a home page, archiving it, and then manually re-creating a brand new home page with identical fields. It would have the same Version (assuming it was saved the same number of times) but it would have a different ID (RecordID in versions table).

I hope that explains things!

kinglozzer commented 6 years ago

I hope that explains things!

Perfectly 😁