Mediendatenbank streikt nach Update

[frabron]

So, ich habe grad mal durch den Code gesehen und der Query wird folgendermaßen zusammengebaut:

Code: Select all

$query =  "SELECT {$cond['distinct']} i.id, {$cond[orderkey]} AS orderkey,  ...

scheinbar ist also der $cond[orderkey] leer. Und wenn man sich den key des arrays ansieht, weiss man auch wieso. Es muss heissen

Code: Select all

$cond['orderkey']

Es müsste also reichen, wenn du den Schlüssel in einfache Anführungszeichen packst.

[garvinhicking]

Hi!

Du könntest auch testweise in der MEdiendatenbankansicht mal gucken ob wenn du die sortierung der (nicht angezeizgten) Bilder änderst das Problem verschwindet.

Ansonsten habt ihr die Stelle gut gefunden; in der include/functions_images.inc.php findet sich folgendes:

Code: Select all

    if (substr($order, 0, 3) === 'bp.') {
        $cond['orderproperty'] = substr($order, 3);
        $cond['orderkey']   = 'bp.value';
        $order              = 'bp.value';
        $cond['joinparts']['properties'] = true;
    } else {
        $cond['orderkey'] = "''";
    }

Mit MySQL klappt dieses '' as orderkey. Vielleicht probiert ihr für pgsql mal folgendes:

Code: Select all

    if (substr($order, 0, 3) === 'bp.') {
        $cond['orderproperty'] = substr($order, 3);
        $cond['orderkey']   = 'bp.value';
        $order              = 'bp.value';
        $cond['joinparts']['properties'] = true;
    } else {
        $cond['orderkey'] = "'1'";
    }

Grüße,
Garvin

[sws]

Sorry, aber es klappt nicht.

Habe beide Veränderungen in der include/functions_images.inc.php zusammen und wahlweise ausprobiert, aber ich sehe weiterhin keine Bilder in der MedienDB.

Gruß,
Sebastian

[sws]

hallo,

ich habe jetzt nochmals die Abfrage mit echo $query im Browser aktiviert. Was mir dabei auffällt ist, dass bei der bisherigen problematischen Passage weiterhin ein Wert ( in diesem Fall die '1') statt eines Feldnamens generiert wird:

SELECT DISTINCT i.id, '1' AS orderkey, i.name, i.extension, i.mime, --- snipp ---

Ich weiss allerdings nicht, ob das so gewollt ist, da ich mich in PHP nicht auskenne.

Gruß,
Sebastian

[frabron]

Das ist eigentlich nicht schlimm.
Ich hab mal eben s9y auf meiner Postgresql datenbank installiert. Mal sehen, ob ich so herausfinden kann, wo das Problem ist.

Stay tuned

Nachtrag:
Also bei mir läuft die Abfrage so durch. Ich habe wie angekündigt s9y frisch installiert.
Mir scheint, da ist wohl doch etwas bei deinem Update auf die neue Version schiefgegangen. Ich denke, wir sollten deine Tabellen mal mit meinen vergleichen, um herauszufinden, ob da Abweichungen sind.
Die Haupttabelle in der Abfrage ist ja serendipity_images, dann weiter noch serendiptiy_authors, serendipity author_groups und serenditity_access.

ich poste hier mal den SQL Code der Tabellen den du dann mit deinen abgleichen solltest

serendipity_images

Code: Select all

CREATE TABLE serendipity_images
(
  id serial NOT NULL,
  name character varying(255) NOT NULL DEFAULT ''::character varying,
  extension character varying(5) NOT NULL DEFAULT ''::character varying,
  mime character varying(255) NOT NULL DEFAULT ''::character varying,
  size integer NOT NULL DEFAULT 0,
  dimensions_width integer NOT NULL DEFAULT 0,
  dimensions_height integer NOT NULL DEFAULT 0,
  date integer NOT NULL DEFAULT 0,
  thumbnail_name character varying(255) NOT NULL DEFAULT ''::character varying,
  authorid integer DEFAULT 0,
  path text,
  hotlink smallint,
  realname character varying(255) NOT NULL DEFAULT ''::character varying,
  CONSTRAINT serendipity_images_pkey PRIMARY KEY (id)
)

serendiptiy_authors

Code: Select all

CREATE TABLE serendipity_authors
(
  realname character varying(255) NOT NULL DEFAULT ''::character varying,
  username character varying(32) DEFAULT NULL::character varying,
  "password" character varying(32) DEFAULT NULL::character varying,
  authorid serial NOT NULL,
  mail_comments smallint DEFAULT 1::smallint,
  mail_trackbacks smallint DEFAULT 1::smallint,
  email character varying(128) NOT NULL DEFAULT ''::character varying,
  userlevel integer NOT NULL DEFAULT 0,
  right_publish smallint DEFAULT 1::smallint,
  CONSTRAINT serendipity_authors_pkey PRIMARY KEY (authorid)
)

serendipity_author_groups

Code: Select all

CREATE TABLE serendipity_authorgroups
(
  groupid integer NOT NULL DEFAULT 0,
  authorid integer NOT NULL DEFAULT 0
)

serenditity_access

Code: Select all

CREATE TABLE serendipity_access
(
  groupid integer NOT NULL DEFAULT 0,
  artifact_id integer NOT NULL DEFAULT 0,
  artifact_type character varying(64) NOT NULL DEFAULT ''::character varying,
  artifact_mode character varying(64) NOT NULL DEFAULT ''::character varying,
  artifact_index character varying(64) NOT NULL DEFAULT ''::character varying
)

Falls du nicht wiesst, was du da siehst: Das sind im Prinzip die Tabellendefinitionen mit Spaltennamen und Spaltentypen. Siehst du da Unterschiede zu deinen Tabellen?

[sws]

O.K, alle Tabellen- und Felddefinitionen stimmen überein. Lediglich bei serendipity_auhtors ist das Feld 'username' nicht direkt hinter 'realname', sondern am Schluss, aber mit den passenden Werten. Dürfte also nichts ausmachen.

Bleibt wohl doch nur ein rollback mit pg_restore und ein neues update...

Gruß,
Sebastian

[frabron]

Sorry, da habe ich auch grad keine Ideen mehr. Ich habe sogar deine Daten in meine DB eingefügt - und es geht auch damit, sogar mit dem leeren ,'' orderfield

[quote=sws]
ERROR: 'default_with_oids' is not a valid option name
ERROR: Unable to identify an ordering operator '<' for type '"unknown"'
Use an explicit ordering operator or modify the query
[/quote]

deutet darauf hin, dass aus irgendeinem Grund bei dir nicht sortiert werden kann, der < meint wohl dann DESC in dem query. Aber das sortiert ja nach dem date Feld und das ist ein popeliger Integer ...
Fragen über Fragen ...

Der erste Fehler resultiert glaube ich aus deiner Postgresql Version, die kennt die Funktion default_with_oids noch nicht. Vielleicht entwickelt sich ja daraus ein Fehler. Ich weiss auch nicht, welche Postgresql Versionen von s9y unterstützt werden, da schweigt sich das Manual zu den Requirements der Datenbankversionen aus. 7.4 ist ja auch schon ein wenig in die Jahre gekommen ...

[sws]

Hallo frabron,

Der erste Fehler resultiert glaube ich aus deiner Postgresql Version,

Wahrscheinlich nicht nur der erste Fehler. Die Version packt's wohl insgesamt nicht mehr so ganz .

7.4 ist ja auch schon ein wenig in die Jahre gekommen ...

Da hast Du natürlich recht. Aber ich müsste den gesamten Server neu aufbauen, und dazu habe ich z.Z.t gar keine Lust. Selbst das Umheben auf MySQL wäre wohl nicht der Hit, da ich noch die UraltVersion 3.23 habe. Wahrscheinlich muss ich mir mal nen Ruck geben und das alles neu machen.

Jedenfalls Danke für die Geduld und Hilfe an alle.

Gruß,
Sebastian