Plugin bricks OID-IP and RDAP on systems with 50.000+ OIDs #17
Comments
|
Hi Daniel, I added a new PRE-version:
Question: Please, can you take a look into the new |
|
...I'm not quite sure why implementsFeature was removed? Was it because of the new Interfaces, or did I an accident? |
|
ToDo:
|
|
I did additonal commits to provide compatibillity to the composer plugin and add your funding, so this is the commit you have to review: |
implementsFeature() is depreacted some time ago. To include a "feature", you now just need to include a real PHP interface, which must start with "INTF_OID_", so that the OIDplus Autoloader knows that this interface is optional and non-critical. |
|
I should hat remember.
It should work this way (I have tested it successfully with the io4- plugin before):
EDIT: composer-plugins should be required first in the composer.json require list, before the other dependencies!!! |
|
Ooops, sorry! WEID ist wieder dabei: 52f3005 |
|
Hallo Till, Ein paar Anmerkungen / Fragen:
|
|
Im alten Code hast Du zwei arrays, eins mit der Verknüpfung orig<-> alt und ein array mit alt<->orig.
Was das replace into betrifft würde ich vorher einen zusätzlichen Select query ausführen und dann ggf. entsprechend das Insert ausführen wenn der Eintrag (in der altids Tabelle) nicht vorhanden ist? Vielleicht kannst Du das irgendwie in einem query (ich müsste erst googeln...)? |
|
|
|
Sorry, hab das vielleicht nicht ganz richtig verstanden: Man könnte das in einem Background-Script/Cronjob lösen ALLE Einträge zu berechnen/einmal zu requesten, z.B.??? |
|
Mal zur Klarstellung kurze Frage wie das gedacht ist:
|
|
Noch ein Performance-Tipp: Statt Arrays sollte man Traversables iterieren! |
|
Hallo Till, ich teste das morgen gleich mal aus.
Aktuelles Verhalten:
Neues Verhalten:
PS: Es sind übrigens 64.000 OIDs und ca. 400.000 Logbucheinträge in meinem Produktivsystem. OIDplus kommt gewaltig an die Grenzen und ich muss viele Entscheidungen überdenken. Ein guter Stresstest... EDIT: OIDplusPagePublicObjects arbeitet wie folgt... (Also nicht mit 404 handler) // --- Try to find the object or an alternative
$test = $this->tryObject($id, $out);
if ($test === false) {
// try to find an alternative
$alternatives = $this->getAlternativesForQuery($id);
foreach ($alternatives as $alternative) {
$test = $this->tryObject($alternative, $out);
if ($test !== false) break; // found something
}
}
if ($test !== false) {
list($id, $obj, $objParent) = $test;
} else {
$objParent = null; // to avoid warnings
} |
|
--> fixed in 2f7190d |
Auf das Löschen eines Objekts kannst du mit dem Interface TODO: Hier bitte folgende Funktionen implementieren:
==> Ausgelagert in Issue #19 |
|
Ok... ich erinnere mich wieder, warum wir den Quatsch mit "readAll" machen mussten! Folgendes Beispiel: Die OID Aber NICHT umgekehrt. Denn eine Hash-Funktion geht ja nur in eine Richtung. Wenn ich also rechts oben in der GoTo-Box den String Deswegen habe ich in Durch die Lookup-Tabelle fällt zwar |
|
Idee:
|
|
Es gibt hier große Denkfehler...
Fixed in ab89e8e (zumindest mit einem unsauberen Hack...) |
|
`Aber NICHT umgekehrt. Denn eine Hash-Funktion geht ja nur in eine Richtung. Wenn ich also rechts oben in der GoTo-Box den String guid:605e40cf-d500-3d1b-8100-63bf368203a1 eingebe, dann muss er alle Objekte durchschauen, ob irgendein Objekt behauptet, dass guid:605e40cf-d500-3d1b-8100-63bf368203a1 eine Alt-ID von ihm ist.`
|
|
Hallo Till, ja, er muss durch die ganze Tabelle durchgehen, denn ansonsten ist der folgende Case nicht abgedeckt: Vereinfacht gesagt, ich versuche (TODO: Ich muss mal prüfen, ob es vielleicht möglich wäre, die kanonisierten AltIds in die Tabelle einzutragen, dann geht es vielleicht mit dem direkten Lookup) Bzgl. Cronjob: Ja, wir können auch CLI. In diesem Fall ruft |
|
Oder? |
|
|
|
|
|
Generell, für die meisten DB-Designs, so hab ich das jedenfalls bisher gesehen (?), empfiehlt es sich Tabellen mit Keys und Relationen anzulegen und separate Tabellen für andere Sachen/Attribute wie z.B. description, RA, Title, usw... im Extremfall für jeden Container eine Tabelle oder key,value,id Tabellen oder ähnliches...? |
|
...P.S.: Sorry: Hab bisher Erfahrung mit MySQL/MariaDB, SQLite und minimal PostgreSQL,
|
|
Ja, PDO unterstützen wir ja auch, aber der SQL-Dialekt ist bei jeder Sprache anders. Deswegen ist es eine große Herausforderung, alle DBMS abzudecken. |
|
Hallo Daniel, Ich habe das teilweise rückgängig gemacht und OIDplus::prefilterQuery in saveAltIdsForQuery hinzugefügt/verschoben: Viele Grüße EDIT: https://registry.frdl.de/plugins/frdl/publicPages/1276945_rdap/rdap/rdap.php?query=oid%3A1.3.6.1.4.1.37553 Ob es aber auch performanter ist wie ich behaupte? Ich vermute es habe es aber nicht gemessen!?! |
|
Als eine ID kanonisieren oder als wie ausgezeichnet als alternative behandeln??? :-) Edit: Wenn dann aber nur im jeweiligen Array des Eintrags und nicht in dem der gesamten DB-Tabelle!?! |
|
Solution for the first problem: Include weid to the alt-id plugin. The altid section at the bottom of the page could hard-coded filter out "oid => weid" entries, because weid is already described in the notation part. I will do it this way. |
|
But that reminds me, if we re-add this, then there will be double output for prefiltered stuff in OID-IP again. |
|
Hallo Daniel, es wird in print_r($res) alles angezeigt mit WEID und altIds, aber es hat keinerlei Auswirkungen, d.h. ich sehe nichts davon auf der ObjectPage und nicht im RDAP und nicht im OID-IP/Whois. mh? |
|
Answer 1: Why isn't it shown in OID-IP? Because in then we have an OID-IP output of If I change it back to then we have the problem in OID-IP and OID-RDAP show Answer 2: Why isn't it shown in OID-RDAP? I can't tell, because OID-RDAP crashes on my system if I have 50k+ OIDs. Answer 3: Why isn't it shown in the GUI Object Page? It turns out that The "alt id" topic becomes very uncomfortable.... |
|
Furthermore, getAltIds() has an array of OIDplusAltId which is a tuple of (NS, ID, Description, Suffix, MoreInfoUrl). while The reason for this is simple:
I wish these two could be combined though, because it is confusing. I begin to think OID-IP and OID-RDAP should rather show |
|
GUI shows OID-IP shows OID-RDAP shows We must that make equal. GUI, OID-IP, and OID-RDAP should show the same things and not 3 different APIs. What a mess |
Ich fasse mal zusammen:
|
|
Ja, stimmt, da war ja das Ding mit dem Reverse-Lookup... (Das für die Suche in der "Goto" Box gelten soll, aber dem User im "Forward"-Lookup nicht angezeigt werden sollte) Ich versuche mal eine Lösung zu skizzieren. Lass uns mal bitte zuerst folgendes probieren: Grundidee: getAltIds() ist das, was der User sehen soll, in GUI, OID-IP, und OID-RDAP. Und getAlternativesForQuery() soll nur intern verwendet werden, für Lookups, um eine "Query" des Users zu berichtigen.
Wenn wir das so machen, dann bleibt eigentlich nur noch ein einziges Problem, nämlich wie WEID den Usern in OID-IP und OID-RDAP angezeigt wird. Dafür hätte ich folgenden Lösungsansatz: |
|
|
|
Ich habe es oben korrigiert. Ich meinte saveAltIdsForQuery, nicht getAlternativesForQuery |
|
Wenn WEID in getAltIds() reinkommt, und getAltIds() die einzige Quelle für saveAltIdsForQuery ist, dann haben wir WEID automatisch überall drin. |
|
Ich versteh irgendwie das Problem grad nicht mit WEID?
|
|
Ich möchte ja, dass alles (GUI, OID-IP, OID-RDAP) ausschließlich auf getAltIds() läuft (dort ist WEID im Moment nicht drin). Dann würde WEID wegfallen. Damit es aber wieder reinkommt (damit der Benutzer es in OID-IP and OID-RDAP sehen kann), wird WEID dann in getAltIds() aufgenommen. Ist also nur zum Anzeigen. Für Redirecten hat das glaube ich keine Auswirkungen. Dass WEID in der DB drin steht, ist dann eher so ein Nebenprodukt, das daher kommt, dass getAltIds() verwendet wird. |
|
Für meine Tabelle altids sind altids erstmal altids, da spielt es doch keine Rolle welche "Sorte" altid das ist, das dient doch dem schnelleren reverse-lookup!? |
|
Probieren wir es doch einfach mal so aus, wie ich es oben skizziert habe :-) Wie gesagt, der Inhalt der DB ist im Moment überhaupt nicht wichtig. Du sollst nur saveAltIdsForQuery wieder so rückgängig machen, dass nur getAltIds() reinkommt und nicht den extra WEID code. Denn dieser WEID code wird dann verschoben in den OIDplus-Core unter getAltIds(). |
|
Danke. Ich probiere jetzt mal bei mir was aus, und melde mich dann gleich wieder. |
|
Hallo Till,
In der GUI Page steht WEID nun oben und unten. Unten könnte man es ausblenden... aber andererseits, ist ja nicht so schlimm, wenn da eine zusätzliche Zeile ist. Mehr Werbung für WEID :-)
|
|
Hallo Daniel, 👍 Punkt 5: Da hab ich noch Fragen: Das RDAP mit altIds funktioniert bereits: https://registry.frdl.de/plugins/frdl/publicPages/1276945_rdap/rdap/rdap.php?query=oid%3A1.3.6.1.4.1.37553.8.8.2 $obj = OIDplusObject::findFitting($query);
if(!$obj){
// If object was not found, try if it is an alternative identifier of another object
$alts = OIDplusPagePublicObjects::getAlternativesForQuery($query);
foreach ($alts as $alt) {
if ($obj = OIDplusObject::findFitting($alt)) {
$query = $obj->nodeId();
break;
}
}
// Still nothing found?
if(!$obj){
$out['error'] = 'Not found';
if(true === $this->useCache){
$this->rdap_write_cache($out, $cacheFile);
}
return $this->rdap_out($out);
}
} else {
$query = $obj->nodeId();
}getAlternativesForQuery ist ja für das reverse, look-up, die altIds bzw. das object haben wir ja noch nicht.
` |
|
$oidip_generator = new OIDplusOIDIP();
list($oidIP, $dummy_content_type) = $oidip_generator->oidipQuery($query);?!? |
|
Hallo Till, |
|
OFFTOPIC: Eine ganz andere Sache bzgl. OID-IP: aber im neuen OID-IP nicht mehr. Ist das so gewollt? |
|
Hallo Daniel, Edit: hab das nochmal korrigiert $obj->nodeId(true), |
|
Alles klar. Jetzt erscheint es wieder bei mir. |
|
Ich habe jetzt noch SQL Server hinzugefügt.
Von meiner Seite aus kann diese Version des Plugins nun veröffentlicht werden. |
|
|
|
Sorry, hab das release schon getätigt, aber beginne sofort mit dem nächsten #19 ab morgen!
EDIT: Hatte zu schnell gelesen und mich auf das Plugin bezogen, im core macht eine function isCronjob() vl. natürlich Sinn. |
|
(Habe den Kommentar zu Cron/SAPI in #20 hinzugefügt) |
Hello Till,
The ViaThinkSoft OID RA has gained 50.000+ OIDs in a private arc, and it turns out that your plugin will crash (30 seconds timeout) the OID-IP and OID-RDAP if there are so many OIDs in the database.
I had to implement a dirty emergency fix to make my system work again:
https://github.com/danielmarschall/oidplus/blob/master/plugins/frdl/publicPages/altids/OIDplusPagePublicAltIds.class.php#L112
We need to find a solution to make this work properly. The parsing and alt-id generation is too slow so we cannot do it for all OIDs every time the user visits the page. If we cache it, then we need to take care that the cache does not refreshed at once, otherwise we would have a crash again.
The text was updated successfully, but these errors were encountered: