{"push_id":963738491,"size":7,"distinct_size":7,"ref":"refs/heads/master-lvm_unif_pr","head":"86657f620e1eefd09251908512d745146d2f9f0d","before":"805e9572c421c3e3b8e9f35775a034dc87875013","commits":[{"sha":"994c131a87252f8a5e782bf7b93ff5b39ebc8ad0","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Transform the is_name_valid() into an instance method\n\nApart from the tests we alway call this code on a particular instance. And\nsometimes it's impossible to just tell if a name is valid without looking on\nsome other properties of the object.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/994c131a87252f8a5e782bf7b93ff5b39ebc8ad0"},{"sha":"69311b7cb6fa975d70d98c09de9d501c0bad3449","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Add a decorator for guarding methods and properties with a property\n\nSometimes we need to prevent a method from being called or property from being\nevaluated if some conditition is not satisfied. The most common case is to check\nvalue of some property of the given object. For example, it only makes sense to\ncall the lv.merge() method if 'lv' is a snapshot. Things like this can be\nfacilitated by a decorator that makes sure 'lv' is snapshot for example by\nchecking its 'is_snapshot' property. The code then looks like this:\n\n@requires_property(\"is_snapshot\")\ndef merge(self):\n    # the actual merge goes here\n\nOn an LV that is not a snapshot a ValueError is raised.\n\nOf course, the decorator can be made even more generic if it turns out in the\nfuture we need it to be.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/69311b7cb6fa975d70d98c09de9d501c0bad3449"},{"sha":"7e43747d2f42176833f84ce874e2d95dc69df182","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Add a test for the to-be-used @type_specific decorator\n\nWhen objects of various (sub)types need to be represented by a single class\n(e.g. because their (sub)types can change in time), it's nice to implement the\n(sub)type specific code in mixin classes the single resulting class inherits\nfrom. With thatthere are two (major) options how to implement the methods of\nsuch \"ultimate\" class:\n\n1) Have gigantic ifs at the beginning of the methods making sure the right code\n   is executed for the particular object and its (sub)type.\n2) Implement and use the @type_specific decorator that makes sure the method\n   of the right mixin class is called.\n\nThis adds an example implementation of 2) included in the test. A generic\n@type_specific decorator would be even more complex and harder to use which is\nwhy the decorator is tailored for the particular class and lives under its\nnamespace.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/7e43747d2f42176833f84ce874e2d95dc69df182"},{"sha":"b1e25ce179aa84a4548b97bc221c1c823e470a86","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Rewrite the code for representing LVs\n\nHaving specific classes for various types of LVs is nice because Python makes\nsure the right code is executed based on the type (class) of the LV. However, a\nbig drawback of this is that it is not possible to change the type (class) of\nthe object once it is created. This makes things like 'lvconvert' or even thin\nsnapshot creation and activation impossible to represent.\n\nThus we need to represent all LVs with single class making a lot of decisions on\nour own. However, that doesn't mean we have to put all the code into a single\nclass. By utilizing some nice tricks, we can easily put type-specific code into\ntype-specific mixin classes and make the final/ultimate class inherit from\nthem. That way the type of an LV is more a dynamic property than a\nonce-and-for-always-given thing.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/b1e25ce179aa84a4548b97bc221c1c823e470a86"},{"sha":"7a56a0a62372c2979145905a1951511fe2064c5c","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Adapt our code to changes in the representation of LVs\n\nAll LVs are now instances of a single class. The type is determined by the\nproperties of the object like its segment type, whether it has a parent LV\n(internal LVs) or an origin (snapshots). Thus we need to make sure the right\nvalues are passed in all the places we create LV objects.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/7a56a0a62372c2979145905a1951511fe2064c5c"},{"sha":"db8261dbfe459ab73de47e5b6534b3f1e98f64c2","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Adapt our tests to the changes in representation of LVs\n\nNo changes in values or API except for how LVs are created.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/db8261dbfe459ab73de47e5b6534b3f1e98f64c2"},{"sha":"86657f620e1eefd09251908512d745146d2f9f0d","author":{"email":"32b71423c0dbe58cc7229f648f881967a836ef95@redhat.com","name":"Vratislav Podzimek"},"message":"Document the LV class unification changes in the release notes\n\nTo give some basic hints to users as well as future developers and maintainers\nof Blivet.","distinct":true,"url":"https://api.github.com/repos/vpodzime/blivet/commits/86657f620e1eefd09251908512d745146d2f9f0d"}]}