[gelöst] Feeds importiert nicht

Wie sieht denn dein Importer aus ? Da müsstest du schon ein paar konkrete Angaben machen - vlt. liegt der Fehler auch an der Feed-Quelle (was immer es auch ist CSV / XML/ RSS) selbst.. Da kann man nur raten..

SteffenR

der Feed ist eine CSV delimited by semikolon, wie sie von excel als TXT-Datei verarbeitet wird.
Ich habe sie jedoch aus einer mySQL-Tabelle als Excel-CSV-Format exportiert.

Als GUID habe ich die laufende Recordnumber der mySQL-Tabelle genutzt, da sie das einzig eindeutige Merkmal ist.
Diese läuft von 1 bis 1565 (oder so ähnlich)

Es ist eine Flat-Table, die nur Textfelder enthält, für die es jeweils ein Pendant im content_type gibt.

Damit es zu keinen Problemen bei leeren Feldern kommt, habe ich alle Felder als Optional angegeben (außer dem Titel-Feld).

Der Import läuft auch durch, es wird jedoch nur ein leerer Datensatz gespeichert, es kommt aber am Ende die Meldung, es wären 15xx Datensätze geändert worden.

Da es sich um ein quasi jungfräuliches Drupan handelt, kann es keine Datensätze geben.

Ich habe auch versucht irgendwelche Fragemente in der Datenbank zu finden, und war nicht fündig.

Hallo,

mal als Nebelkerze...

Kann es denn sein das halt alle Datensätze als gleich angesehen werden und nur einer importiert wird,
und dann im weiteren Verlauf des Imports 15xx mal geändert wird.

Beim "Prozessor" gibts doch diese Einstellung:
"Do not update existing nodes "

Viele Grüße,
Markus

Dies würde bedeuten, dass er keinen einzigen gültigen Datensatz erkennt.
Er erzeugt nämlich einen leeren Datensatz, und in der Tabelle stehen definitiv fast 1600 unterschiedlichen Datensätze.

Ich schaue es mir morgen nochmal an. Jetzt ist es zu spät, und ich hatte ein paar Bierchen. Danach sollte man nichts wichtiges mehr tun ;-)

Und wenn Du nicht den Umweg über den Export aus der DB und dann den Import per CSV gehst, sondern gleich direkt aus der Source-DB importierst? feeds_sql funktioniert da wunderbar

http://drupal.org/project/feeds_sql

Das Problem scheint wirklich die ID zu sein, die er nicht in eine GUID umsetzen möchte.
Ich habe einen INT-Wert als Autonumber von der Datenbank generieren lassen, weil es bequem ist, und ich bei allen anderen Feldern nicht garantieren kann, dass sie eindeutig sind.

Dieses Problem hätte ich also auch mit der Datenbank-Direktmethode.

Dennoch hole ich mir jetzt mal das Modul und teste es.

Danke erstmal.

denn die Datenbank ist Drupal nicht bekannt und liegt auf einem anderen Host, sogar auf einem anderen Server.
Das wird von dem Modul nicht unterstützt.

Schade eigentlich.

Nichtsdestotrotz, das Importproblem muß ich eh' lösen, da ich es auch in anderen Sites brauche.

Hier ist es nur das initiale Laden, in anderen Projekten muss ich damit regelmäßige Abgleiche fahren.

Ich teste weiter - dennoch bin ich für jeden Tipp dankbar.

Einen Hinweis, wie ich den Prozess debugen kann, könnte ich gerade ganz gut gebrauchen.

Irgendwie die Quelle anzeigen, und daneben, was feeds für den Record aufbereitet?

Es ist einfach eine Bücherliste. Da ein Titel aber mehrfach vorkommen kann, kann ich diesen nicht als eindeutiges Kennzeichen verwenden.
Wie legt Drupal die NodeIDs fest?

Wenn ich keine Angabe, wird dann eine generiert?

Hier das Mapping:

Das ist der content_type:

Und so sieht die Tabelle aus:

Versuch es doch mal ohne die ID, also auch das Unique rausnehmen. Der Import funktioniert auch ohne ein unique field und die ID wird dann automatisch von Drupal vergeben. Und dann, wie schon erwähnt, im Node processor das Updaten der Nodes ausschalten. Rhein theoretisch müsste dann jeder Datensatz eine Node ergeben.

Ich habe den Unique Key und die Spalte ID weggelassen.

Jetzt hat er mir die richtige Anzahl Nodes erzeugt - aber alle Nodes waren leer.

Die Zuordnung hat nicht funktioniert. Kein einziges Feld hat einen Inhalt.

Zum Glück gibt es im Import den delete button.

Ich verstehe nicht, was hier schief geht.

Ein gern genommener Fehler in diesen Zusammenhang ist die Codierung (sollte utf8 sein) die man evtl. mit einem passenden Editor konvertieren sollte. Schwerwiegender ist aber das eingestellte Zeilenende!! Das muß auf Unix-Endung (LF) stehen, damit der Import funktioniert.

Beste Grüße
Werner

Stimmt denn auch Dein Trennzeichen? Sprich, hast Du beim Import auch wirklich das eingestellt, was bei der Datei verwendet wird? Was anderes fällt mir als mögliche Fehlerquelle sonst nicht mehr ein...

hat schließlich den Erfolg gebracht.

Windowsprogramme hängen immer ein CRLF ans Ende eines Datensatzes.

Außerdem musste ich das Excel-Exportergebnis in Notepad öffnen, und dann als UTF8 speichern, weil sonst die Umlaute nicht gepasst hätten.

Das heißt aber auch, dass man alle Dateien, die von einem Windowsprogramm erzeugt wurden, nochmals interpretieren muss, ehe sie eingelesen werden können.

Das ist lästig.

Schön das das Problem hier gelöst wurde. Ich habe dasselbe Problem, bekomme es aber nicht genau gebacken.

Wie muß die CSV-Datei genau aussehen? Ich habe meine Testdatei mal angehangen: UTF8-Format ohne BOM, Unix-Zeilenumbruch.
Leider ist nirgends beschrieben, wie die Datensätze aussehen müssen. Ich habe schon Hochkommata (") als Spaltenbegrenzer versucht (sh. Anhang) - dann auch mal wieder ohne. 2 Datensätze sind in der CSV drin, einer wird importiert - und der ist bis auf den Inhaltstyp (Artikel) leer.

Die Begrenzer der Felder müssen die gleichen sein, wie die der Feldnamen.

Entweder du verwendest KOMMA, dann aber überall, oder du verwendest SEMIKOLON, dann aber auch überall.

Die Einstellung im Import muss natürlich dazu passen.

Dann möchte ich mich nochmal für das Wiederaufwärmen dieses Themas entschuldigen...

Bei meinen ersten Tests war das Trennzeichen noch überall ein Semikolon - wobei dort zwei leere Datensätze ohne Inhaltstyp angelegt wurden. Dann habe ich mir einen Import-Typ "Artikel" erstellt, der wohl mit meinem Inhaltstyp "Artikel" kollidierte. Nach dem Aufruf von /import bekam ich Import- und Inhaltstyp zusammen angezeigt - so als sollte ich jetzt einen neuen Artikel anlegen und dabei auch noch gleichzeitig was importieren. Die Verwirrung war komplett. Aber diese Kollision ist wohl ein Bug in Drupal.

Danach habe ich das Feeds-Modul teilweise übersetzt und bin darauf gestoßen, daß GUID wohl benötigt wird (Was auch immer das sein soll. GUID hatte ich bei meinen ersten Versuchen vergessen anzugeben.). Dabei habe ich auch das node_template.csv mal runtergeladen, wo die Kopfzeile ja mit Komma getrennt wird. Die habe ich dann in meine CSV-Datei eingesetzt. Das paßt natürlich nicht mit einem Semikolon zusammen...

legt Drupal sich intern eine an.

Wichtig ist ein eindeutiges Kennzeichen, wenn Datensätze aktualisiert werden sollen.

Bei einem einmaligen Import muss es nicht sein.
Es ist dann auch besser, update existing nodes auszuschalten.