con_art_spec Tabelle: Spalte client => idClient?

knb · Beitrag von **knb** » Do 27. Okt 2005, 09:45

Eigentlich müsste doch aus Konsitenzgründen in der Tabelle cat_art_spec
(ab 4.5) die Spalte "client" zu idclient umbenannt werden, oder etwa nicht?

Schliesslich ist die Spalte definiert als Integer(10) und nicht als varchar(n)

--VORHER
CREATE TABLE contenido_dc110_art_spec (
idartspec int(10) NOT NULL default '0',
`client` int(10) NOT NULL default '0',
lang int(10) NOT NULL default '0',
artspec varchar(255) NOT NULL default '',
online tinyint(1) NOT NULL default '0',
artspecdefault tinyint(1) NOT NULL default '0',
PRIMARY KEY (idartspec),
KEY `client` (`client`),
KEY lang (lang)
)

--NACHHER ?
CREATE TABLE contenido_dc110_art_spec (
idartspec int(10) NOT NULL default '0',
idclient int(10) NOT NULL default '0',
lang int(10) NOT NULL default '0',
artspec varchar(255) NOT NULL default '',
online tinyint(1) NOT NULL default '0',
artspecdefault tinyint(1) NOT NULL default '0',
PRIMARY KEY (idartspec),
KEY `client` (`client`),
KEY lang (lang)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Und was bitte schön ist eigentlich eine Artikelspezifikation?

knb · Beitrag von **knb** » Do 27. Okt 2005, 09:57

--NACHHER ?
CREATE TABLE contenido_dc110_art_spec (
idartspec int(10) NOT NULL default '0',
idclient int(10) NOT NULL default '0',
lang int(10) NOT NULL default '0',
artspec varchar(255) NOT NULL default '',
online tinyint(1) NOT NULL default '0',
artspecdefault tinyint(1) NOT NULL default '0',
PRIMARY KEY (idartspec),
KEY `client` (`client`),
KEY lang (lang)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

ach ja ...
also natürlich gilt das auch für Spalte "lang":
lang int(10) NOT NULL default '0' => idlang int(10) NOT NULL default '0',

--NACHHER ?
CREATE TABLE contenido_dc110_art_spec (
idartspec int(10) NOT NULL default '0',
idclient int(10) NOT NULL default '0',
idlang int(10) NOT NULL default '0',
artspec varchar(255) NOT NULL default '',
online tinyint(1) NOT NULL default '0',
artspecdefault tinyint(1) NOT NULL default '0',
PRIMARY KEY (idartspec),
KEY idclient (idclient),
KEY idlang (idlang)
)

timo · Beitrag von **timo** » Do 27. Okt 2005, 10:52

Theoretisch ja, aber praktisch benennen wir aus Kompatibilitätsgründen keine Spalten mehr um.

Eine Artikelspezifikation (wird noch umbenannt, da mit so einem Namen keiner etwas Anfangen kann) ist eine Art Typisierung.

knb · Beitrag von **knb** » Do 27. Okt 2005, 11:36

Also Spalten werden in Zukunft nicht mehr umbenannt, neue Tabellen ja .
... naja. Soll mir alles recht sein. Man muss es nur wissen.

Ich gehe also erstmal davon aus dass die Tabelle in Version 4.6 noch nicht von irgendwelchen Backendscripts benutzt wird.

Aber welche Artikel-Typen sind denn vorgesehen, beispielsweise?

timo · Beitrag von **timo** » Do 27. Okt 2005, 12:00

knb hat geschrieben:Also Spalten werden in Zukunft nicht mehr umbenannt, neue Tabellen ja .
... naja. Soll mir alles recht sein. Man muss es nur wissen.

Ich gehe also erstmal davon aus dass die Tabelle in Version 4.6 noch nicht von irgendwelchen Backendscripts benutzt wird.

Naja ein "gutes" Backupscript zieht alle Tabellen in einer Datenbank raus und backupt sie

z.b. über SHOW TABLES.

Aber welche Artikel-Typen sind denn vorgesehen, beispielsweise?

Du kannst die Typen selbst unter Administration->Mandanten definieren und dann über die Artikeleigenschaften zuweisen.

Beitrag von **HerrB** » Do 27. Okt 2005, 13:25

Ist nicht so wichtig, aber nicht, dass ihr aneinander vorbeiredet:

knb hat geschrieben:Backendscripts

= Skripte von Contenido nutzen es oder nicht (wofür ist das wichtig, knb?)

timo hat geschrieben:Backupscript

= ist klar...

Gruß
HerrB

timo · Beitrag von **timo** » Do 27. Okt 2005, 13:29

Ups, da hab ich mich verlesen

Was genau meinst du dann mit einem "Backendscript"?

knb · Beitrag von **knb** » Fr 28. Okt 2005, 11:55

HerrB hat es schon richtig verstanden, ich meinte irgendein php script in $cfg['path']['contenido'] .

ich dachte dass man die Spalten durchaus umbenennen könnte solange die Tabelle noch nicht genutzt wird. Da noch keine "offiziellen" scripts darauf zugreifen, ist auch nicht zu erwarten dass contenido-user schon anwendungen geschrieben haben die auf die tabelle zugreifen.

aber ich hatte gestern noch nicht selbst nachgeschaut ob es nicht doch schon php code gibt der darauf zugreift. Jetzt aber habe ich nachgeschaut, und siehe da: art_spec wird genutzt,

Es scheint der Fall zu sein in

./classes/class.artspec.php
./classes/class.search.php
./includes/cfg_sql.inc.php
./includes/functions.general.php
./tools/upgrade.php

Wobei mir aufgefallen ist dass diese Funktion aus ./includes/functions.general.php
wohl einen Bug enthält :

function deleteArtspec ($idartspec)
{
global $db, $cfg;
$sql = "DELETE FROM ".$cfg['tab']['art_spec']." WHERE idartspec=".$idartspec."";
$db->query($sql);

$sql = "UPDATE ".$cfg["tab"]["art_lang"]." set artspecid=0 WHERE artspec=$idartspec";
$db->query($sql);
}

Das UPDATE statement kann in der SET Klausel nicht funktionieren denn eine Spalte artspecid gibt es nicht, in keiner Tabelle. in art_lang heisst sie artspec

Vielleicht ist es ja schon gefixt in v4.5.4 und höher ?

Bei näherer betrachtung gibt es anscheinend etliche integer(10) Spalten die in der referenzierenden Tabelle (wo das Attribut Foreign key ist) NICHT mit id* beginnen, aber in der referenzierten Tabelle (wo das Attribut Primary Key ist) id* heissen.
Ich nehme mal an dass es bei den meisten dieser Attribute auf die historische Entwicklung zurückzuführen ist.

Nur "client" sollte es wirklich nicht sein. Und "lang" auch nicht.

timo · Beitrag von **timo** » Fr 28. Okt 2005, 12:09

Naja das Problem ist immer:

Wird ein Feature eingebaut, so wird es meistens bei uns (four for business) in Projekten verwendet. Deshalb ist von unserer Seite ein Umbenennen nicht möglich, da es leider keine Möglichkeit gibt, in allen Projekten selbige Umbenennung zu machen.

Den Bug werde ich gleich fixen

Beitrag von **Dodger77** » Fr 28. Okt 2005, 14:09

knb hat geschrieben:ich dachte dass man die Spalten durchaus umbenennen könnte solange die Tabelle noch nicht genutzt wird. Da noch keine "offiziellen" scripts darauf zugreifen, ist auch nicht zu erwarten dass contenido-user schon anwendungen geschrieben haben die auf die tabelle zugreifen.

Also ich nutze die Funktion der Artikelspezifikationen durchaus schon in einigen Projekten.

Beitrag von **HerrB** » Fr 28. Apr 2006, 16:44

Dieser Fehler ist noch drin:

Code: Alles auswählen

$sql = "UPDATE ".$cfg["tab"]["art_lang"]." set artspecid=0 WHERE artspec=$idartspec";

muss

Code: Alles auswählen

$sql = "UPDATE ".$cfg["tab"]["art_lang"]." set artspec=0 WHERE artspec=$idartspec";

lauten.

Verschoben nach Bugs.

Gruß
HerrB

Beitrag von **HerrB** » Do 8. Jun 2006, 16:16

Done.

Gruß
HerrB