Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mpsonntag
Copy link
Contributor

@mpsonntag mpsonntag commented Mar 30, 2020

This PR is supposed to show by example how a cardinality implementation (see issue #361) could look like and provides more grounds for discussion.

The current PR adds the basic cardinality implementation for Property.values. It provides

  • an update in format.
  • an update in the Property.__init__.
  • val_cardinality accessor methods.
  • Parser methods to read the cardinality after saving to file for all three supported file formats.
  • Cardinality validation example.

Tests will still be pushed to this PR.

The PR should serve as a basis for discussion before the cardinality feature can be extended to sections and properties as well.

@mpsonntag
Copy link
Contributor Author

mpsonntag commented Mar 30, 2020

As further basis for discussion here is an outline of the current cardinality features:

  • format addition

    • cardinality for sections (sec_cardinality), properties (prop_cardinality) and values (val_cardinality)
    • they will not be required attributes
    • cardinality requires additional attributes to the format for both section and property. Since this previous libraries will simply ignore the additional serialized attributes only an increase in the micro part of the version number should be required.
  • setting cardinality

    • cardinality can be assigned the following three options: empty (None, etc), one int, a 2 int tuple
    • if none (or empty) is set, the cardinality is unrestricted and the cardinality attribute is None as well.
    • if one int is set, this will be the allowed maximum and set as tuple (None, int)
    • other combinations (min..max) can only be set by assigning an appropriate tuple: (int, None), (None, int) or (int, int)
  • file serialization

    • if cardinality is none, it will not be serialized to file
    • if set to a tuple, cardinality will also be serialized to file as a tuple
  • cardinality check options

    • cardinality checks are implemented via validations, which for now will only elicit appropriate warnings, not errors
    • [optional] the validation could be set to error as well. by default on file loading all validation errors are simple warnings while on file save these validations remain errors and have to be fixed. This could be a way to enforce obeying cardinality on save.
    • [optional] alternatively cardinalities could be checked by a hardcoded routine in the setters of the respective sections or properties, but that could lead to loss of information on file loading. Having soft checks and warning via validations seems to be the safer option for now
  • open questions:

    • what should happen when a cardinality is set that violates the current status of an entity e.g. setting max 5 on a value that already has 10 entries.

@coveralls
Copy link

coveralls commented Mar 30, 2020

Coverage Status

Coverage increased (+0.6%) to 76.329% when pulling 79e5acf on mpsonntag:card into d9d5223 on G-Node:master.

Copy link
Member

@achilleas-k achilleas-k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I assume most of this functionality will be reused for Section->Section and Section->Property.

@mpsonntag
Copy link
Contributor Author

When we have figured out the details in the discussion, the concept will also be applied to cardinalities of Sections and Properties, yes.

@mpsonntag
Copy link
Contributor Author

I'm preparing tests for all new features and will push them once we are happy with the current state of the PR.

@mpsonntag
Copy link
Contributor Author

Pushed tests for hopefully all added features.

Windows does not support fetching the systems stdout
via the 'sys.__stdout__' magic method in all cases.
@achilleas-k
Copy link
Member

@jgrewe I guess you want to review the changes since your approval before merging?

@jgrewe jgrewe merged commit 4fcfcc9 into G-Node:master Apr 7, 2020
@mpsonntag mpsonntag deleted the card branch April 9, 2020 11:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants