On Fri, 2016-03-18 at 09:57 +0100, Ancor Gonzalez Sosa wrote: > I have a design decision to take and I need advise. Please, stay on > topic (i.e. "design a ruby layer to query the not-under-discussion > structure of devicegraphs coming from libstorage"). > > While writing the code for the new proposal we needed to query a > devicegraph (hopefully you all know what a devicegraph is in the > libstorage-ng world) for things like: > > - all free spaces in a given subset of disks (candidates for install) > - all filesystems in the same subset, not caring if they are directly > on > the disk or on a partition table > > While writing tests, we found we had similar requirements but without > constraining those queries to a set of disks (i.e. we wanted to list > the > free spaces, partitions, filesystems, etc. at some point of the whole > devicegraph). > > We came up with the idea of a Devicegraph query object that is > already > partially implemented and seems to solve our problems. But if we are > going to start using it in many places (there will be calls in almost > every single test) I want to make sure the API does not suck much. I > have two alternatives and would like to hear/read opinions. > > As usual, we don't want to over-engineer it, but we don't want to > throw > it away with the next requirement change either. > > Explanation by example, hopefully enough (ping me if it's not). > Please > read both options before commenting (I actually like more the second > one). > > Option 1 - Only a DevicegraphQuery class > > https://gist.github.com/ancorgs/9c628ef0f4fa717a2817 > > But, what about something like this? > more_fine_query.disks > > With the implementation I have in mind, it would return the same that > fine_query.disks, but some people could expect it to return only > disks > from fine_query.disks which, as additional requirement, contain any > primary partition. > > This, of course, can be solved documenting which restrictions are > honored by each query method (for example, #disks would only honor > #with_disk while #partitions would honor both #with_disk and > #with_partition). > > That is, the expected direction of the hierarchy (like "a filesystem > can > be expected at some point below a disk, but not the other way > around") > would be in the source code and documentation of the methods at > DevicegraphQuery. > > Option 2 - A WhateverQuery class per type of object > > https://gist.github.com/ancorgs/a98597fa9a5e348eaaac > > This is my preferred option for several reasons, even if it means > implementing more classes (something that is not bad, per se). > > First of all, the direction of the hierarchy is reflected in the API > (DiskQuery has a method #filesystems which returns a FilesystemQuery > but > not the other way around). > > It also makes possible (and easy) to write specific filters for a > given > type of query, like > # Get an array of free spaces big enough to be used for something > FreeDiskSpaceQuery.new(devicegraph).useful.to_a > > I also find it more readable for the tests and very Ruby-like (even > Rails-like), but that can be a matter of taste. > > Opinions?
I'd go for the second approach because it's more readable and it can be extended in a easier way. Regards, Imo -- Imobach González Sosa YaST Team at SUSE LINUX GmbH
signature.asc
Description: This is a digitally signed message part
