Re: Tools based on whois -t output.
= "Mike Norris" <mnorris@hea.ie> writes: = * = * Good idea, Ambrose. I presume the asterisk is a = * place-holder and will appear in the case of attributes = * that are neither look-up nor inverse keys? = =Yes. The aim is to make the output easier to read. I =suppose an "-" character or a blank space could be used =instead. I will think about it. I'd ask you to come up with a somewhat consistent format. A blank by itself doesn't sound like a good idea from the SW engineering point of view. How about having the brackets anyway, but no tag inside, or a hyphen, or an asterisk. I think it would be easier to parse in the end, if we can expect a constant number of (non-blank :-) fields. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------
Hi, Wilfried ! "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes: * = "Mike Norris" <mnorris@hea.ie> writes: * = * * = * Good idea, Ambrose. I presume the asterisk is a * = * place-holder and will appear in the case of attributes * = * that are neither look-up nor inverse keys? * = * =Yes. The aim is to make the output easier to read. I * =suppose an "-" character or a blank space could be used * =instead. I will think about it. * * I'd ask you to come up with a somewhat consistent format. A blank by * itself doesn't sound like a good idea from the SW engineering point of * view. * * How about having the brackets anyway, but no tag inside, or a hyphen, or * an asterisk. I think it would be easier to parse in the end, if we can * expect a constant number of (non-blank :-) fields. This appears to be the consensus so far. It would make writing tools easier if the number of fields was constant. So the output would look like route: [mandatory] [single] [look-up key] descr: [mandatory] [multiple] [] or route: [mandatory] [single] [look-up key] descr: [mandatory] [multiple] [-] I appreciate your taking the time to send your comments. Thanks. If you have anymore questions, please contact <ripe-dbm@ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration. * * Wilfried. * -------------------------------------------------------------------------- * Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at * Computer Center - ACOnet : * Vienna University : Tel: +43 1 4065822 355 * Universitaetsstrasse 7 : Fax: +43 1 4065822 170 * A-1010 Vienna, Austria, Europe : NIC: WW144 * --------------------------------------------------------------------------
Hi database friends! Sorry for late response. CONTENTS: --------- 1. Re: Tools based on whois -t output. 2. Adapted libray template.pl (if useful) 1. Re: Tools based on whois -t output ------------------------------------- It's a great idea to give more information about the database objects by an whois -t output. When we used the ripe database software at our site to define and store own business data objects we modified it in a way that complete information about the definition of the database objects is given by a whois -t output. I.e the output looked like short longname uniqe key rec optionality cardinality ------------------------------------------------------------------ a1 attribute1 UNIQ mandatory single a2 attribute2 KEY mandatory single a3 attribute3 optional multiple a4 attribute4 optional single a5 attribute5 KEY REC mandatory multiple where UNIQ describes the attributes who form the unique key (identifier) of that object KEY describes that this attribute is a search field (whois query) REC describes that it is used for an reference lookup. It was very useful for us to have this complete information about the definition of the database objects (we had a really great amount of objects and attributes) to understand the given datamodel. I'll put the adapted libray template.pl to the end of this mail (may it's useful for someone who is using the ripe database software too). Kind regards, Markus Bock 2. Adapted libray template.pl (if useful) ------------------------------------------------------------------------ -- SCHNIPPP----------------------------------- # $RCSfile: template.pl,v $ # $Revision: 2.0 $ # $Author: ripe-dbm $ # $Date: 1996/08/08 10:47:30 $ # template.pl - spits out a template for an object, based on the config # file. Assumes that the config has already been read. # Takes object type as input. Outputs to currently selected output. # BEGIN_DTAG # # Modified by DTAG Internet Services for internal use # # We want to have an extended output of a template for an object, based # on the config file: # - additional information for unique keys # - additional information for keys # - additional information for recursiv queried objects # - different output style. # # To do this we have to adapt this library. # # Markus Bock, DTAG, Internet Services # # mb@nic.dtag.de 961017 # #END_DTAG sub Template { local($output, $type) = @_; # BEGIN DTAG local(%uniq) = (); local(%key) = (); local(%rec) = (); local(%mand) = (); local(%mult) = (); local(%guar) = (); local(%obsoleted) = (); # END DTAG foreach (split(/\s+/, $OBJMAND{$type})) { $mand{$_} = 1; } foreach (split(/\s+/, $OBJMULT{$type})) { $mult{$_} = 1; } ## ANOTHERBEGIN foreach (split(/\s+/, $UNIQ{$type})) { $uniq{$_} = 1; } ## ANOTHEREND ## ANOTHERBEGIN foreach (split(/\s+/, $KEYS{$type})) { $key{$_} = 1; } ## ANOTHEREND ## ANOTHERBEGIN foreach (split(/\s+/, $RECUR{$type})) { $rec{$_} = 1; } ## ANOTHEREND foreach (split(/\s+/, $OBS{$type})) { $obsoleted{$_} = 1; } local(@obsoleted)=(); print $output "\n"; # implement the tabular look printf $output "%-5s %-20s %-5s %-5s %-5s %-13s %-13s\n" , "short", "longname", "uniqe", "key", "rec", "optionality", "cardinality"; printf $output "%-5s %-20s %-5s %-5s %-5s %-13s %-13s\n" , "-----", "--------------------", "-----", "-----", "-----", "-------------", "-------------"; foreach (split(/\s+/, $OBJATSQ{$type})) { if ($obsoleted{$_}) { # push(@obsoleted, sprintf("%-12s %-12s\n", $ATTL{$_}.":", "[obsoleted]")); # We allow longer attribut (long-) names push(@obsoleted, sprintf("%-25s %-25s\n", $ATTL{$_}.":", "[obsoleted]")); } else { # printf $output "%-12s %-12s %-12s\n", # printf $output "%-25s %-25s %-25s\n", # $ATTL{$_}.":", # $mand{$_} ? "[mandatory]" : "[optional]", # $mult{$_} ? "[multiple]" : "[single]"; printf $output "%-5s %-20s %-5s %-5s %-5s %-13s %-13s\n" , $ATTR{$_}."", $ATTL{$_}."", $uniq{$_} ? "UNIQ" : "", $key{$_} ? "KEY" : "", $rec{$_} ? "REC" : "", $mand{$_} ? "mandatory" : "optional", $mult{$_} ? "multiple" : "single"; # # $guar{$_} ? "[guarded]" : "" ; } } foreach (@obsoleted) { print $output $_; } } 1; SCHNAPP------------------------------------------
* = * Good idea, Ambrose. I presume the asterisk is a * = * place-holder and will appear in the case of attributes * = * that are neither look-up nor inverse keys? * = * =Yes. The aim is to make the output easier to read. I * =suppose an "-" character or a blank space could be used * =instead. I will think about it. * * I'd ask you to come up with a somewhat consistent format. A blank by * itself doesn't sound like a good idea from the SW engineering point of * view. * * How about having the brackets anyway, but no tag inside, or a hyphen, or * an asterisk. I think it would be easier to parse in the end, if we can * expect a constant number of (non-blank :-) fields.
This appears to be the consensus so far. It would make writing tools easier if the number of fields was constant.
I'm not convinced that having a fixed three fields (maybe one empty) rather than a list of space separated fields makes tools easier to write. It might be better to have an extensible syntax so we could use it with the proposed time stamp field that users might see but won't be able to change. A [auto] or [fixed] flag could then be useful. How about... -t generates a template that lists each of the attributes together with a list of its flags. Flags are enclosed in square brackets and separated within the list by white space. Tools builder should be aware that new flags may be defined in the future. Existing flags are... [mandatory] - An object MUST NOT contain zero instances of this attrib. [optional] - An object MAY contain zero instances of this attrib. [single] - An object MUST NOT contain more than one instance of this attrib. [multiple] - An object MAY contain more than one instance of this attrib. [look-up key] - Attrib is indexed. [inverse key] - Attrib is in the 'reverse' index. (use -i) Further, if tool builders want this type of facility it might be useful to include the other flags that are defined in the 'config file'. [unique-key] - Attrib is (part of) the unique key. [reference] - Value of attrib is a reference to another object. Though I think initial intention was to provide more documentation for users rather than tools ;-) Chris.
participants (4)
-
Chris Fletcher -
Markus Bock -
RIPE Database Administration -
Wilfried Woeber, UniVie/ACOnet