afbeelding van florisla

node_save: zelf node nummer kiezen

Hoi allemaal,

Ik probeer bestaande content te importeren in Drupal 6 via node_save: http://api.drupal.org/api/function/node_save .

Dat lukt vrij aardig, maar ik merk dat Drupal de nummering van de nodes zelf wilt beheren.

Ik zou de node nummers liever zelf kiezen om ze gelijk te houden aan de bestaande ID's van de paginas. Op die manier kan ik al mijn oude URLs gemakkelijk URL-rewriten naar Drupal node URLs en vermijd ik dus 404 errors.

Ik overweeg om een trucje toe te passen, door alle content te importeren in oplopende volgorde van IDs en wanneer er bepaalde nummers niet gebruikt worden om dan een SQL query uit te voeren: "ALTER TABLE node AUTO_INCREMENT={nieuw nummer};". De eerste teste wijzen uit dat dit kan lukken.

Lijkt dit een goede strategie of maak ik het mezelf te moeilijk?

Auteur: 
florisla
afbeelding van Xano
Door Xano op 16 maart, 2008 - 15:16

Ik moet bekennen dat ik niet helemaal snap wat jouw oplossing precies was. Wat ik waarschijnlijk zou doen was de bestaande node_save() functie kopiëren en zo aanpassen, dat er handmatig een nodeID ingevoerd kan worden (dus in principe geldt dan dat de ID van de oude node ingevoerd wordt in de nieuwe tabel) Als je hiermee klaar bent zet je in de nieuwe tabel gewoon auto-increment weer aan.

Nederdev.nl | De community voor designers en developers

My name is Bart - web & events
iDEAL, OmniKassa, en meer.

afbeelding van florisla
Door florisla op 16 maart, 2008 - 15:43

Wel,

Drupal 5 hield in de tabel 'sequences' bij welke ID de volgende was. Drupal 6 laat dit over aan de database en schrijft geen expliciete nummers weg -- de databank vult deze zelf automatisch in.

De query vertelt tegen de database dat hij het opgegeven nummer als volgende waarde moet gebruiken. Dit is hoe de query er in mijn script uitziet:


db_query("ALTER TABLE {node} AUTO_INCREMENT = %d ;", $wanted_id);
node_save($node);

Merk op dat $wanted_id een ID is van de node die op de volgende regel pas aangemaakt wordt.

Om hetzelfde effect te bereiken via de gewone Drupal code zou ik niet enkel node_save() moeten aanpassen, maar ook zaken in de schema API waar ik niet vertrouwd mee ben. Daar zie ik dus een beetje tegen op.

Misschien bestaat er een module om de node ID te wijzigen nadat de node is aangemaakt?

afbeelding van Xano
Door Xano op 16 maart, 2008 - 16:04

Naderhand alle NIDs wijzigen is erg lastig, want dan moet jij handmatig voor elke node gaan invullen wat het moet worden. Het eenvoudigts lijkt mij de methode van auto-increment uitschakelen -> nodes importeren en met een eigen scriptje de NIDs overzetten (bijvoorbeeld door node_save() te kopiëren en te verbouwen) -> auto-increment inschakelen. Dit kost je het minste werk, voor zover ik kan zien.

Nederdev.nl | De community voor designers en developers

My name is Bart - web & events
iDEAL, OmniKassa, en meer.

afbeelding van george@dynapres.nl
Door george@dynapres.nl op 16 maart, 2008 - 19:52

Ik zou geen trucs toepassen, Drupal de nid's laten beheren en "standaard" URL aliassen gebruiken. Deze kun je definiëren direct bij import.

Dynapres.nl

afbeelding van florisla
Door florisla op 16 maart, 2008 - 20:36

Zoals gezegd wil ik mijn oude URLs niet ongeldig maken. Als de IDs veranderen dan moet ik zelf een look-up tabel voorzien om de omzetting te maken (tussen oude ID en nieuwe ID).

Maar inderdaad, da's lang geen slechte oplossing.

Door jpoesen op 19 maart, 2008 - 07:44

1: wat is de vorm van je oude urls? kan je eens een voorbeeld geven?

2: is je oude content een oudere versie van Drupal of niet?

Ik zou vermijden om in te grijpen in de node ids. Dat wordt heel snel heel vies. Zoals George zegt, kan tijdens import een path-alias definiëren: die kan je dan telkens op het oude pad zetten.

Als het niet mogelijk is om tijdens import het pad te zetten, kan je nog altijd programmatorisch de path-alias van elke node zetten door door je nodes te lopen, een node_load te doen, path-alias te zetten, en een node_save te doen.

Als je oude urls van de vorm /node/x waren en je wil dat behouden, denk ik dat de oplossing van Xano de meest realistische is, namelijk op het niveau van apache met een lookup table werken en voor een bepaalde reeks urls zorgen dat er een rewrite gebeurt naar de overeenkomstige nids.

J.

afbeelding van florisla
Door florisla op 19 maart, 2008 - 14:33

1. en 2. Zie onder: geen Drupal maar Nucleus in de vorm /index.php?itemid=1958

Ik ben me ervan bewust dat het niet de properste oplossing is, maar in dit geval begin ik met een maagdelijke Drupal installatie dus er is geen gevaar voor bestaande Drupal content.

De vraag is of een URL met query string erin wel geschikt is om er een path alias van te maken.

Anyway, het is aan het lukken met behoud van de IDs dus de vraag is niet meer zo actueel.

Binnen een paar weken zou de site in de 'Showcase' sectie van het forum moeten verschijnen.

afbeelding van Xano
Door Xano op 16 maart, 2008 - 20:56

Hoe stel jij dat voor dan George? Punt is dus dat de oude links werken met /node/[nid] volgens mij. Heeft niks met aliassen te maken. Wil je dat deze blijven werken, dan is het volgens mij het makkelijkst wel een truuk uit te halen en te zorgen dat oude en nieuwe NIDs gelijk zijn (wel goed opletten wat je doet, want NIDs worden niet alleen in de node-tabel bijgehouden!) en daarna voor de nieuwe nodes met Pathauto aliassen te maken. Met aliassen de oude paden naar de nieuwe laten verwijzen vind ik een nog smeriger truuk als ik eerlijk moet zijn. Dan 'vervuil' je onnodig je aliastabel.

My name is Bart - web & events
iDEAL, OmniKassa, en meer.

afbeelding van florisla
Door florisla op 17 maart, 2008 - 00:14

In mijn geval komt de oude content niet uit Drupal, maar uit Nucleus. De URLs hebben dus een andere structuur: index.php?itemid=[nid] .

Ik weet niet of dat een geldig pad is om een alias op te maken, maar ik ga het dus ook niet proberen ;-)

afbeelding van george@dynapres.nl
Door george@dynapres.nl op 17 maart, 2008 - 22:04

Deze oude URLs kun je niet definiëren middels een Drupal path/alias (per node). Als je een omzettingstabel hebt gemaakt na import kun je met wat Rewrite regels in combinatie met RwriteMap in de Apache configuratie er voor zorgen dat de oude URLs worden doorverwezen naar de nieuwe.

Dynapres.nl

afbeelding van Xano
Door Xano op 18 maart, 2008 - 16:13

Snap niet helemaal wat je bedoelt, maar het klinkt ingewikkeld. Omzettingstabel? Ik zou gewoon alle /index.php?itemid=[nid] met .htaccess doorverwijzen naar /node/[nid] (wel zorgen dat deze redirectregel bovenaan je .htaccess file staat) en dan in Drupal zelf zorgen dat de oude IDs overeenkomen met de nieuwe. Je moet voor dat laatste dus wel tijdelijk Drupal lichtelijk hacken, maar nadat je klaar bent met overzetten kan je de hack ongedaan maken en als dat klaar is merk je nergens meer wat van. Lookuptables zijn gewoon een extra performance drain: niet doen dus.

Nederdev.nl | De community voor designers en developers

My name is Bart - web & events
iDEAL, OmniKassa, en meer.

afbeelding van florisla
Door florisla op 19 maart, 2008 - 14:01

Wat george bedoelt is om een omzettingstabel te definieren (oude nummer X komt overeen met nieuwe node ID Y).

RewriteMap is blijkbaar een optie van de apache URL rewriting engine (instelbaar via .htaccess bestand) om dergelijke mapping te doen. Ik vermoed dat dat best efficient is.

Ik heb uiteindelijk ervoor gekozen om de nummers gelijk te houden, en da's goed gelukt.

afbeelding van Xano
Door Xano op 19 maart, 2008 - 17:24

Het nadeel aan lookuptables of extra aliases is de performance drain. De waaghals/perfectionist in mij zou dan lekker gaan klooien en de IDs veranderen :P

Maar hoe heb je het nu precies gedaan? Ben wel nieuwsgierig :)

Nederdev.nl | De community voor designers en developers

My name is Bart - web & events
iDEAL, OmniKassa, en meer.

afbeelding van florisla
Door florisla op 30 maart, 2008 - 20:29

Ik heb ook lekker geklooid natuurlijk :-)

Ik merkte dat Drupal 6.1 wat vriendelijker was voor manuele inserts in de databank dan 5.x (geen sequences tabel etc.).

Dus in plaats van tijd te investeren in de node_save() methode heb ik terug mijn SQL bulk import strategie (zie eerder forum topic) bekeken. En dat bleek heel goed te gaan.

Mijn hoofdreden was dat de node IDs een issue waren waar ik tegenaan liep, maar dat er daarna misschien nog lijken uit de kast konden vallen. Ik denk bvb. aan 'last modified' datetime en zo. In de SQL bulk import methode heb je meer directe controle over de data die uiteindelijk in de databank komt. En het databank schema van Drupal is wel elegant genoeg om snel te leren.

Enkel de node_comment_statistics tabel was wat lastiger om in SQL op te vullen (er was geen vergelijkbare tabel in mijn bron-data). Ik heb uiteindelijk op drupal.org een stukje PHP gevonden dat deze goed opvult. Code gewoon in een node gestoken met PHP filter, en nu bezoek ik die pagina na een databank refresh.

Bookmark and Share

Drupal is een geregistreerd merk van Dries Buytaert. | Powered by Pantheon.

Drupal.be/Drupal.nl is de website van de Nederlandstalige Drupalgemeenschap.

onomatopee