This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Adding nic handles to contact objects without one
- Previous message (by thread): Adding nic handles to contact objects without one
- Next message (by thread): [Fwd: FAILED:]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Luis Silva Damas
joao at ripe.net
Tue Mar 2 17:35:26 CET 1999
Hello, "Bernard Steiner" <bs at eunet.ch> writes: * * This is a non-advantage because * Actually it is from a database point of view because you increase coherency between the objects and their definition. It also facilitates further work on the DB to eliminate ambiguity. * > RIPE NCC can do it if users wish to. Of course this can only be done for * > references by name corresponding to names that are unique in the database, * * > otherwise we wouldn't know who to assign the object to and we shouldn't. * * the existing ambiguity will *not* disappear. * Yes. That's what I said in my previous mail. Ambiguity will not disappear just by doing this. The users with that kind of objects would have to fix them. The RIPE NCC will aid the users through the database consistency project. This is a first step that doesn't solve all the problems but makes it easier for the future and adds a bit more coherency to the Database. So, I think we agree and I hope you can support the addition of the NIC handles to the objects that don't have one yet. * > * Then you have the problem where these people created a new person * > * object for themselves when nic-hdls became mandatory and left their * > * old person object for dead. How will you overcome these old person * > * objects ? * * Let me also point out that there appear to exist (inetnum) objects that * reference non-existing person objects. If a new person object is created * such that the name happens to match, that person will then inherit the * reference. This can't happen anymore. Now the DB code will not allow a deletion of a person/role object that is still being referenced by other objects. The ones that are already there will have to be fixed, again by the user with our help if it is requested. The consistency project will soon start publishing reports on the occurrence of various types of inconsistencies in the database together with instructions on how to fix them. * This may or may not be intentional (e.g. replacing a person objec * t * with a role object where the new role object has the same handle as the old * person object :-) * On the other hand, just because someone who used to have something to do * with an inetnum in (say) Norway and another Person with the same name but * from (say) Switzerland appears in the database, if the .no guy's person reco * rd * got deleted, then the .ch guy has nothing to do with the .no inetnums. * Even as of now, I cannot delete old person objects in cases where names are * referenced and objects with the same name are still in the database :-( * * What I am getting at is that if you add handles to all person objects and * then update the references from person names to handles, the effect is not * necessarily correct. You cannot make a non-consistent database consistent by * automatic measures. * Again I agree. That's what I stated in the previous mail. No amount of code can subsitute a reasonable person so the real cleanup will need some user intervention. * Just my ECU 0.02 Most welcome [although the ECU is now gone :-) ] Regards, Joao Damas RIPE NCC * Greetings * Bernard
- Previous message (by thread): Adding nic handles to contact objects without one
- Next message (by thread): [Fwd: FAILED:]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]