Noch ein Bug

[Joerg Rossdeutscher]

Moin,

Es scheint so zu sein, dass wenn man die alten fontlinge auf der Platte
hat und auf die aktuelle Version upgraded, dass man in der
MySQL-Datenbank im feld "font_path" das "binary"-Attribut nicht gesetzt
bekommt.
Ich bin jetzt am überlegen, wie man da überhaupt vernünftig rankommt.
Gehen sollte auf jeden Fall

ALTER TABLE fonts CHANGE font_path font_path varchar(255) binary not
null;


...die frage ist nur, ob man da noch durchblick, wenn an allen Ecken und
Enden an der Datenbank rumgeschraubt wird.

Wäre es nicht sinnvoll, EIN zentrales sql-File zu haben, welches mit
obiger Syntax alle Felder auf den Soll-Stand ändert? Inklusive Indices
und so?


Gruß,
Ratti

--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Samstag, 11. Juni 2005 14:59 schrieb Ratti:
> Es scheint so zu sein, dass wenn man die alten fontlinge auf der
> Platte hat und auf die aktuelle Version upgraded, dass man in der
> MySQL-Datenbank im feld "font_path" das "binary"-Attribut nicht
> gesetzt bekommt.

*aua*

> Ich bin jetzt am überlegen, wie man da überhaupt vernünftig rankommt.
> Gehen sollte auf jeden Fall
>
> ALTER TABLE fonts CHANGE font_path font_path varchar(255) binary not
> null;
>
> ...die frage ist nur, ob man da noch durchblick, wenn an allen Ecken
> und Enden an der Datenbank rumgeschraubt wird.

Als Hotfix fürs nächste Release brauchen wir jedenfalls sowas irgendwo
in --update-database - auch wenn es nicht so "schön" ist.

Kann die "Änderung" eigentlich etwas kaputtmachen, wenn die Spalte schon
binary ist? Wenn nicht: rein damit.

Noch ein Problem für eine spätere "saubere" Lösung:
    show fields from fonts;
zeigt die Spalte nicht mehr als "varchar(255) binary", sondern schlicht
als "varchar(255)" an. Könnte eine Änderung in MySQL 4.1.10 von SuSE
9.3 sein :-/

PHPmyAdmin zeigt dann übrigens in der Spalte "Kollation" den Wert
"latin1_bin" statt latin1_swedish_ci wie bei den anderen Textspalten.
Wenn ich jetzt noch wüsste, wie ich an die "Kollation"-Infospalte
(zwecks Auswertung) komme...

> Wäre es nicht sinnvoll, EIN zentrales sql-File zu haben, welches mit
> obiger Syntax alle Felder auf den Soll-Stand ändert? Inklusive
> Indices und so?

Mein Gedanke war, das komplett über den database_assistant zu machen.

Für Indizies funktioniert das ja schon - aber die Datenbankstruktur habe
ich mir noch nicht vorgenommen. In meiner Planung steht das ja
bekanntlich "irgendwann nach dem Release" und vor Hurd ;-)

BTW: Das Setzen des binary-Attributs mag ja noch ein einfacher Fall
sein, aber vielleicht brauchen wir auch mal zusätzliche Spalten o. ä.
(und haben noch eine Version später eine Änderung an dieser Spalte).
Mit einem vorgefertigten SQL-File dürften wir da schnell an Grenzen
stoßen, Perl ist da deutlich flexibler.


Gruß

Christian Boltz
--
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This message was infected under the terms of the GNU General Public
License.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Joerg Rossdeutscher]

Hallo,

Kurz ein Zwischenergebnis.

Am Samstag, den 11.06.2005, 14:59 +0200 schrieb Joerg Rossdeutscher:

> Moin,
>
> Es scheint so zu sein, dass wenn man die alten fontlinge auf der Platte
> hat und auf die aktuelle Version upgraded, dass man in der
> MySQL-Datenbank im feld "font_path" das "binary"-Attribut nicht gesetzt
> bekommt.
> Ich bin jetzt am überlegen, wie man da überhaupt vernünftig rankommt.
> Gehen sollte auf jeden Fall
>
> ALTER TABLE fonts CHANGE font_path font_path varchar(255) binary not
> null;

Ich habe mir eine kleine chroot-Umgebung gebaut und dort DBI, DBD und
MySQL aus aktuellen Sourcen reingebaut.

Bisheriges Zwischenergebnis nach einer frischen fontlinge-Installation:


mysql> DESCRIBE fonts;
+----------------+--------------+------+-----+---------+----------------+
| Field          | Type         | Null | Key | Default | Extra          
+----------------+--------------+------+-----+---------+----------------+
| font_id        | int(4)       |      | MUL | NULL    | auto_increment
| font_path      | varchar(255) |      | PRI |         |                
| font_name      | varchar(255) |      |     |         |                
| font_datatype  | varchar(4)   |      |     |         |                
| font_filetype  | varchar(8)   |      |     |         |                
| font_kategorie | int(2)       | YES  | MUL | NULL    |                
| font_fullinfo  | text         | YES  |     | NULL    |                
| font_complete  | int(1)       | YES  |     | NULL    |                
+----------------+--------------+------+-----+---------+----------------+
8 rows in set (0,00 sec)


Es wird kein "binary" angezeigt!

Jetzt versuche ich, ein Duplikat zu erzeugen:

mysql> INSERT INTO fonts SET font_path="test";
Query OK, 1 row affected (0,00 sec)

mysql>  INSERT INTO fonts SET font_path="test";
ERROR 1062 (23000): Duplicate entry 'test' for key 1


Das wird ordnungsgemäss abgewiesen.

Jetzt erzeuge ich ein case-insensitives Duplikat:

mysql>  INSERT INTO fonts SET font_path="Test";
Query OK, 1 row affected (0,00 sec)

Sehr gut! Wäre das Feld nicht binary, hätte die gleiche Fehlermeldung
kommen müssen!


Kurze Prüfung mit SELECT:

mysql> SELECT font_path FROM fonts WHERE font_path="Test";
+-----------+
| font_path |
+-----------+
| Test      |
+-----------+
1 row in set (0,00 sec)

mysql> SELECT font_path FROM fonts WHERE font_path="test";
+-----------+
| font_path |
+-----------+
| test      |
+-----------+
1 row in set (0,00 sec)


Auch OK.


Zunächst erstmal Entwarnung: Wir müssen nichts anpassen.
Warum der Dupecheck beim Kollegen nicht geht, ist dann eine andere
Frage...

Gruß,
Ratti


--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Joerg Rossdeutscher]

Am Sonntag, den 12.06.2005, 21:23 +0200 schrieb Joerg Rossdeutscher:
> Hallo,
>
> Kurz ein Zwischenergebnis.

Und noch eins...

Das Problem ist extrem schwer nachzuvollziehen. Es tritt nur mit
brandneuen mysql-Versionen auf, und auch nur, wenn fonts mit ganz
bestimmten Namen und Formaten beteiligt beteiligt sind.

Es ist wohl das neue VARCHAR BINARY vs. VARBINARY-Verhalten:
Wir haben an mehreren Stellen sowas stehen wie
SELECT blablabla WHERE BINARY x="$egal"

WHERE BINARY geht prima. Dummerweise geht nicht mehr ORDER, da verhält
sich MySQL wieder case-insensitiv und sortiert beliebig.

Der dupecheck macht ein SELECT auf *alle* Fonts und sortiert sie dem
Namen nach. Alles hintereinanderkommende mit gleichem Namen wird
gecheckt. Mit der alten MySQL-Version kam sowas:

Helvetica
Helvetica
Helvetica
Helvetica
helvetica <- kleines "h"!

Mit der neuen Version kommt sowas:

Helvetica
Helvetica
helvetica <- kleines "h"!
Helvetica
Helvetica


Deswegen wird die gleiche Familie zweimal geprüft, und beim zweiten mal
ohne Berücksichtigung des bereits erfolgten Löschvorgangs der ersten
Prüfung.

Es /scheint/ zu klappen, wenn man das Feldformat von font_path und
font_name von VARCHAR[255] ändert auf VARBINARY[255] (Ich muss das
Manual nochmal lesen, da steht was von wegschnippeln der Spaces am
Textende), das bedeutet jedoch:

# Die derzeit "stable" Version der Fontlinge läuft nicht mehr #
# korrekt und verursacht unter aktuellen Versionen von MySQL  #
# Datenverlust.                                               #

Gruß,
Ratti


--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Dienstag, 14. Juni 2005 23:19 schrieb Ratti:
> Am Sonntag, den 12.06.2005, 21:23 +0200 schrieb Joerg Rossdeutscher:
> > Kurz ein Zwischenergebnis.
>
> Und noch eins...
>
> Das Problem ist extrem schwer nachzuvollziehen. Es tritt nur mit
> brandneuen mysql-Versionen auf,

... zum Beispiel mit der von SuSE 9.3...

> und auch nur, wenn fonts mit ganz
> bestimmten Namen und Formaten beteiligt beteiligt sind.

Aufgrund Deines Beispiels tippe ich mal darauf, dass namensgleiche
Fonts, die sich nur in der Groß- und Kleinschreibung unterscheiden,
betroffen sind. Eine weitere Voraussetzung ist, dass mehrere Exemplare
der Schrift vorhanden sind, also irgendwas(2).ttf.

Ob TTF/OTF oder Type1 dürfte IMHO egal sein.

> Es ist wohl das neue VARCHAR BINARY vs. VARBINARY-Verhalten:
> Wir haben an mehreren Stellen sowas stehen wie
> SELECT blablabla WHERE BINARY x="$egal"
>
> WHERE BINARY geht prima. Dummerweise geht nicht mehr ORDER, da
> verhält sich MySQL wieder case-insensitiv und sortiert beliebig.

Mist.

Aber: Da ja der LinuxTag vor der Tür steht, werde ich mal direkt bei den
MySQL-Leuten nachfragen...

> Der dupecheck macht ein SELECT auf *alle* Fonts und sortiert sie dem
> Namen nach. Alles hintereinanderkommende mit gleichem Namen wird
> gecheckt. Mit der alten MySQL-Version kam sowas:
>
> Helvetica
> Helvetica
> Helvetica
> Helvetica
> helvetica <- kleines "h"!
>
> Mit der neuen Version kommt sowas:
>
> Helvetica
> Helvetica
> helvetica <- kleines "h"!
> Helvetica
> Helvetica
>
>
> Deswegen wird die gleiche Familie zweimal geprüft, und beim zweiten
> mal ohne Berücksichtigung des bereits erfolgten Löschvorgangs der
> ersten Prüfung.
>
> Es /scheint/ zu klappen, wenn man das Feldformat von font_path und
> font_name von VARCHAR[255] ändert auf VARBINARY[255]

Stimmt, dann geht es wieder ohne Fehlermeldung.
(Ungetestet: Das Ändern von font_name müsste eigentlich reichen.)

Eine weitere Möglichkeit ist das Ändern von "Kollation" per phpMyAdmin
auf ascii_bin - funktioniert auch.

ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
CHARACTER SET ascii COLLATE ascii_bin NOT NULL

latin1_bin funktioniert ebenfalls:

ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
CHARACTER SET latin1 COLLATE latin1_bin NOT NULL

(Jetzt frag aber bitte nicht, was der Unterschied zwischen ascii_bin und
latin1_bin ist ;-)

> (Ich muss das Manual nochmal lesen, da steht was von wegschnippeln der
> Spaces am Textende),

Hast Du die URL gerade parat?

> das bedeutet jedoch:  
>
> # Die derzeit "stable" Version der Fontlinge läuft nicht mehr #
> # korrekt und verursacht unter aktuellen Versionen von MySQL  #
> # Datenverlust.                                               #

Ist der Datenverlust verifiziert?

Da wir ja grundsätzlich vor dem Löschen diffen, tippe ich "nur" auf eine
Fehlermeldung.

Auch meine Versuche haben das bestätigt: Ich bekomme eine unschöne
Fehlermeldung [1], aber die beim Dupecheck gelöschten Fonts sind
wirklich Duplikate - also kein Datenverlust. Entwarnung?


Gruß

Christian Boltz

[1] FATAL ERROR:Could not diff
    «.../crashbase/codex/codex.ttf» and
    «.../crashbase/codex/codex(4).ttf» due different type.

    Warum da "different type" statt "file not found" kommt, müsste ich
    allerdings nachsehen. Moment... (Fontling.pm, sub fontlinge_Diff)

    if (-f $file1 && -f $file2 ) {  # [...]
    } elsif (-d $file1 && -d $file2 ) { # [...]
    } else { # not file-on-file, not dir-on-dir. WTF is this?
            print "FATAL ERROR:Could not diff\n    «$file1» and\n    
                   «$file2» due different type.\n";
            exit 1;
    }

    Stimmt, eine nicht existente Datei ist weder Datei noch Verzeichnis.
    Wir sollten wohl die Fehlermeldung etwas genauer auseinandernehmen
    (sprich: mit -e testen, ob die Dateien existieren. Und zwar vor dem
    else-Zweig.)  ;-)

    Das Problem dürfte sich übrigens in Luft auflösen (bzw. nur ein
    wenig die Performance vermiesen), sobald der Dupecheck auch gleich
    die Datenbank mit aufräumt.

--
It's the goldmaster - there're no bugs ;-)
[Andreas Jäger about SuSE 9.3]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Joerg Rossdeutscher]

Am Sonntag, den 19.06.2005, 02:04 +0200 schrieb Christian Boltz:
> Hallo Ratti, hallo Leute,
> Am Dienstag, 14. Juni 2005 23:19 schrieb Ratti:
> > Am Sonntag, den 12.06.2005, 21:23 +0200 schrieb Joerg Rossdeutscher:

> > Das Problem ist extrem schwer nachzuvollziehen. Es tritt nur mit
> > brandneuen mysql-Versionen auf,
>
> ... zum Beispiel mit der von SuSE 9.3...

Genau.

> > und auch nur, wenn fonts mit ganz
> > bestimmten Namen und Formaten beteiligt beteiligt sind.
>
> Aufgrund Deines Beispiels tippe ich mal darauf, dass namensgleiche
> Fonts, die sich nur in der Groß- und Kleinschreibung unterscheiden,
> betroffen sind. Eine weitere Voraussetzung ist, dass mehrere Exemplare
> der Schrift vorhanden sind, also irgendwas(2).ttf.

Genau. Es müssen mindestens zwei gleichnamige Fonts vorhanden sein, die
durch einen dritten mit anderem Case getrennt werden können.

> > Es ist wohl das neue VARCHAR BINARY vs. VARBINARY-Verhalten:
> > Wir haben an mehreren Stellen sowas stehen wie
> > SELECT blablabla WHERE BINARY x="$egal"
> >
> > WHERE BINARY geht prima. Dummerweise geht nicht mehr ORDER, da
> > verhält sich MySQL wieder case-insensitiv und sortiert beliebig.
>
> Mist.
>
> Aber: Da ja der LinuxTag vor der Tür steht, werde ich mal direkt bei den
> MySQL-Leuten nachfragen...

Erst schlagen, dann fragen.
Siehste, gut, dass ich nicht auf dem Linuxtag bin. Ich habe drei
Urlaubstage in die Fehlersuche investiert - allein zwei davon war der
Fehler hier nicht reproduzierbar. Ich würde die erwürgen.

> > Es /scheint/ zu klappen, wenn man das Feldformat von font_path und
> > font_name von VARCHAR[255] ändert auf VARBINARY[255]
>
> Stimmt, dann geht es wieder ohne Fehlermeldung.
> (Ungetestet: Das Ändern von font_name müsste eigentlich reichen.)

Für diesen Fall ja. Ich wollte es dann gleich komplett krisensicher
machen.

> Eine weitere Möglichkeit ist das Ändern von "Kollation" per phpMyAdmin
> auf ascii_bin - funktioniert auch.
>
> ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> CHARACTER SET ascii COLLATE ascii_bin NOT NULL
>
> latin1_bin funktioniert ebenfalls:
>
> ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> CHARACTER SET latin1 COLLATE latin1_bin NOT NULL

Ich finde im Manual keine Erklärung, was "COLLATE" genau tut. Grob
gesagt scheint es irgendwelche Codepages umzuschalten. Aber was tut
sowas hier:

SELECT _latin1'Müller' COLLATE latin1_german1_ci;


> (Jetzt frag aber bitte nicht, was der Unterschied zwischen ascii_bin und
> latin1_bin ist ;-)

Da wir sowieso 7bit-Ascii verwenden, geht wahrscheinlich auch
kisuaheli_bin, das entscheidende dürfe das "_bin" sein.


> > (Ich muss das Manual nochmal lesen, da steht was von wegschnippeln der
> > Spaces am Textende),
>
> Hast Du die URL gerade parat?

http://dev.mysql.com/doc/mysql/en/binary-varbinary.html

> > das bedeutet jedoch:  
> >
> > # Die derzeit "stable" Version der Fontlinge läuft nicht mehr #
> > # korrekt und verursacht unter aktuellen Versionen von MySQL  #
> > # Datenverlust.                                               #
>
> Ist der Datenverlust verifiziert?

Nein.

> Da wir ja grundsätzlich vor dem Löschen diffen, tippe ich "nur" auf eine
> Fehlermeldung.
>
> Auch meine Versuche haben das bestätigt: Ich bekomme eine unschöne
> Fehlermeldung [1], aber die beim Dupecheck gelöschten Fonts sind
> wirklich Duplikate - also kein Datenverlust. Entwarnung?

Hm. Ja.


> [1] FATAL ERROR:Could not diff
>     «.../crashbase/codex/codex.ttf» and
>     «.../crashbase/codex/codex(4).ttf» due different type.
>
>     Warum da "different type" statt "file not found" kommt, müsste ich
>     allerdings nachsehen. Moment... (Fontling.pm, sub fontlinge_Diff)

>     Stimmt, eine nicht existente Datei ist weder Datei noch Verzeichnis.
>     Wir sollten wohl die Fehlermeldung etwas genauer auseinandernehmen
>     (sprich: mit -e testen, ob die Dateien existieren. Und zwar vor dem
>     else-Zweig.)  ;-)

Ich habe den Text der Fehlermeldung etwas erweitert.

Da es sich um einen "Hoppla. Das hier hätte niemals passieren
dürfen!"-Fehler handelt, sollte das ausreichen.

>     Das Problem dürfte sich übrigens in Luft auflösen (bzw. nur ein
>     wenig die Performance vermiesen), sobald der Dupecheck auch gleich
>     die Datenbank mit aufräumt.

Nein. fontlinge_dupe fordert zunächst eine Liste ALLER Fonts an, nach
Name sortiert. Da steht dann bereits drin:

Helvetica
Helvetica
helvetica <-
Helvetica
Helvetica

Der erste Block löst eine Prüfung aller "Helvetica"s aus. Auch, wenn
diese jetzt aus der DB entfernt werden, sind sie im oben gemachten
"SELECT alles" weiterhin vorhanden und lösen eine zweite Prüfung aus.

Die Übergabe erfolgt nich nach Name, sondern nach id. Der Font mit
dieser id ist aber möglicherweise bereits im ersten Durchgang gelöscht.
Bumm.


Gruß,
Ratti

--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Joerg Rossdeutscher]

Tach,

Am Sonntag, den 19.06.2005, 10:21 +0200 schrieb Joerg Rossdeutscher:

> Genau. Es müssen mindestens zwei gleichnamige Fonts vorhanden sein,
> die durch einen dritten mit anderem Case getrennt werden können.

Uff. Das sollte es gewesen sein.

Die "empty.sql" generiert neue Datenbanken jetzt gleich mit "varbinary"
statt "varchar".

Der database assistant schickt zwei "ALTER" Statements bei
"--update-database", was bei "--phoenix" explizit enthalten ist.

Der war fies.
Done.


Gruß,
Ratti
--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Sonntag, 19. Juni 2005 11:38 schrieb Ratti:

> Am Sonntag, den 19.06.2005, 10:21 +0200 schrieb Joerg Rossdeutscher:
> > Genau. Es müssen mindestens zwei gleichnamige Fonts vorhanden sein,
> > die durch einen dritten mit anderem Case getrennt werden können.
>
> Uff. Das sollte es gewesen sein.
>
> Die "empty.sql" generiert neue Datenbanken jetzt gleich mit
> "varbinary" statt "varchar".
>
> Der database assistant schickt zwei "ALTER" Statements bei
> "--update-database", was bei "--phoenix" explizit enthalten ist.

... und das Suchfeld in der WebGUI ist plötzlich case-sensitiv.

> Der war fies.

Stimmt :-/


Gruß

Christian Boltz
--
Sind wir denn hier im Kindergarten? Kaum is Mama weg, schon haut
Ihr aufeinander rum. Nu is Mama (ich) wieder da und jetzt aber
wieder sinnig hier!!   [Jessica Bleche in suse-linux]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Christian Boltz]

Hallo Ratti, hallo Leute,

(@David: Für Dich habe ich eine Frage ganz ans Ende der Mail gepackt ;-)

Am Sonntag, 19. Juni 2005 10:21 schrieb Ratti:

> Am Sonntag, den 19.06.2005, 02:04 +0200 schrieb Christian Boltz:
> > Am Dienstag, 14. Juni 2005 23:19 schrieb Ratti:
> > > Am Sonntag, den 12.06.2005, 21:23 +0200 schrieb Joerg
> > > Rossdeutscher:
> > >
> > > Das Problem ist extrem schwer nachzuvollziehen. Es tritt nur mit
> > > brandneuen mysql-Versionen auf,
> > > und auch nur, wenn fonts mit ganz
> > > bestimmten Namen und Formaten beteiligt beteiligt sind.
> >
> > Aufgrund Deines Beispiels tippe ich mal darauf, dass namensgleiche
> > Fonts, die sich nur in der Groß- und Kleinschreibung unterscheiden,
> > betroffen sind. Eine weitere Voraussetzung ist, dass mehrere
> > Exemplare der Schrift vorhanden sind, also irgendwas(2).ttf.
>
> Genau. Es müssen mindestens zwei gleichnamige Fonts vorhanden sein,
> die durch einen dritten mit anderem Case getrennt werden können.
>
> > > Es ist wohl das neue VARCHAR BINARY vs. VARBINARY-Verhalten:
> > > Wir haben an mehreren Stellen sowas stehen wie
> > > SELECT blablabla WHERE BINARY x="$egal"
> > >
> > > WHERE BINARY geht prima. Dummerweise geht nicht mehr ORDER, da
> > > verhält sich MySQL wieder case-insensitiv und sortiert beliebig.
> >
> > Mist.
> >
> > Aber: Da ja der LinuxTag vor der Tür steht, werde ich mal direkt
> > bei den MySQL-Leuten nachfragen...
>
> Erst schlagen, dann fragen.
> Siehste, gut, dass ich nicht auf dem Linuxtag bin. Ich habe drei
> Urlaubstage in die Fehlersuche investiert - allein zwei davon war der
> Fehler hier nicht reproduzierbar. Ich würde die erwürgen.

Ich hab sie dann doch nochmal lebend davonkommen lassen ;-)

> > > Es /scheint/ zu klappen, wenn man das Feldformat von font_path
> > > und font_name von VARCHAR[255] ändert auf VARBINARY[255]
> >
> > Stimmt, dann geht es wieder ohne Fehlermeldung.
> > (Ungetestet: Das Ändern von font_name müsste eigentlich reichen.)
>
> Für diesen Fall ja. Ich wollte es dann gleich komplett krisensicher
> machen.

Nebenwirkung auf die WebGUI siehe nebenan.
VARBINARY scheint also auch nicht die optimale Lösung zu sein :-(

> > Eine weitere Möglichkeit ist das Ändern von "Kollation" per
> > phpMyAdmin auf ascii_bin - funktioniert auch.
> >
> > ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> > CHARACTER SET ascii COLLATE ascii_bin NOT NULL
> >
> > latin1_bin funktioniert ebenfalls:
> >
> > ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> > CHARACTER SET latin1 COLLATE latin1_bin NOT NULL
>
> Ich finde im Manual keine Erklärung, was "COLLATE" genau tut. Grob
> gesagt scheint es irgendwelche Codepages umzuschalten. Aber was tut
> sowas hier:
>
> SELECT _latin1'Müller' COLLATE latin1_german1_ci;

Muss ich bei Gelegenheit testen ;-)

> > (Jetzt frag aber bitte nicht, was der Unterschied zwischen
> > ascii_bin und latin1_bin ist ;-)
>
> Da wir sowieso 7bit-Ascii verwenden, geht wahrscheinlich auch
> kisuaheli_bin, das entscheidende dürfe das "_bin" sein.

Gut möglich.

> > > (Ich muss das Manual nochmal lesen, da steht was von
> > > wegschnippeln der Spaces am Textende),
> >
> > Hast Du die URL gerade parat?
>
> http://dev.mysql.com/doc/mysql/en/binary-varbinary.html

Und die schau ich mir jetzt endlich mal an.

> > > das bedeutet jedoch:
> > >
> > > # Die derzeit "stable" Version der Fontlinge läuft nicht mehr #
> > > # korrekt und verursacht unter aktuellen Versionen von MySQL  #
> > > # Datenverlust.                                               #
> >
> > Ist der Datenverlust verifiziert?
>
> Nein.
>
> > Da wir ja grundsätzlich vor dem Löschen diffen, tippe ich "nur" auf
> > eine Fehlermeldung.
> >
> > Auch meine Versuche haben das bestätigt: Ich bekomme eine unschöne
> > Fehlermeldung [1], aber die beim Dupecheck gelöschten Fonts sind
> > wirklich Duplikate - also kein Datenverlust. Entwarnung?
>
> Hm. Ja.

Also Entwarnung ;-)

> > [1] FATAL ERROR:Could not diff
> >     «.../crashbase/codex/codex.ttf» and
> >     «.../crashbase/codex/codex(4).ttf» due different type.
> >
> >     Warum da "different type" statt "file not found" kommt, müsste
> > ich allerdings nachsehen. Moment... (Fontling.pm, sub
> > fontlinge_Diff)
> >
> >     Stimmt, eine nicht existente Datei ist weder Datei noch
> > Verzeichnis. Wir sollten wohl die Fehlermeldung etwas genauer
> > auseinandernehmen (sprich: mit -e testen, ob die Dateien
> > existieren. Und zwar vor dem else-Zweig.)  ;-)
>
> Ich habe den Text der Fehlermeldung etwas erweitert.
>
> Da es sich um einen "Hoppla. Das hier hätte niemals passieren
> dürfen!"-Fehler handelt, sollte das ausreichen.

OK.

> >     Das Problem dürfte sich übrigens in Luft auflösen (bzw. nur ein
> >     wenig die Performance vermiesen), sobald der Dupecheck auch
> > gleich die Datenbank mit aufräumt.
>
> Nein. fontlinge_dupe fordert zunächst eine Liste ALLER Fonts an, nach
> Name sortiert. Da steht dann bereits drin:
>
> Helvetica
> Helvetica
> helvetica <-
> Helvetica
> Helvetica
>
> Der erste Block löst eine Prüfung aller "Helvetica"s aus. Auch, wenn
> diese jetzt aus der DB entfernt werden, sind sie im oben gemachten
> "SELECT alles" weiterhin vorhanden und lösen eine zweite Prüfung aus.
>
> Die Übergabe erfolgt nich nach Name, sondern nach id. Der Font mit
> dieser id ist aber möglicherweise bereits im ersten Durchgang
> gelöscht. Bumm.

Vielleicht sollten wir den Dupecheck noch etwas umprogrammieren und
performance-optimieren.

Derzeit (Pseudocode):

    Gehe durch alle Datenbankeinträge und stoße jedesmal, wenn sich
    font_name ändert, einen Dupecheck an.

Das heißt, dass wir wohl auch für nur einmalig vorkommende Namen den
Dupecheck anstoßen, was immerhin zu jeweils einer überflüssigen
MySQL-Query führt. (Oder täusche ich mich jetzt?)

Vorschlag (Pseudocode):

    Gehe durch alle Datenbankeinträge und führe folgendes aus:
        $font_count[font_name] ++;
    Anschließend gehe durch keys($font_count) und rufe für alle Namen,
    bei denen  $font_count[font_name] > 1  ist, den Dupecheck auf.

Frage: Sind Keys in Perl case-sensitiv?   David?

Der Vorteil wäre jedenfalls, dass wir keine unnötigen Datenbank-Abfragen
mehr machen müssten.


Gruß

Christian Boltz
--
Es ist im Moment recht ruhig, ja. Und das obwohl die ersten 9.3er Pakete
mittlerweile im Umlauf sind. Ob SuSE inzwischen so gut ist, dass die
Leute einfach keine Probleme mehr haben? (je nach eigenen Erfahrungen,
bitte Ironie-Tags setzen, oder eben nicht)
[Manfred Tremmel in suse-linux]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[David Haller]

On Sun, 03 Jul 2005, Christian Boltz wrote:
[..]
>Vorschlag (Pseudocode):
>
>    Gehe durch alle Datenbankeinträge und führe folgendes aus:
>        $font_count[font_name] ++;
>    Anschließend gehe durch keys($font_count) und rufe für alle Namen,
>    bei denen  $font_count[font_name] > 1  ist, den Dupecheck auf.
>
>Frage: Sind Keys in Perl case-sensitiv?   David?

Ja. Laesst sich normalerweise aber durch ein normalisieren der
Hash-Eintraege erschlagen:

    $font_count{ lc($font_name) }++;

    foreach( keys %font_count ) {
        dupecheck($_) if $font_count{$_} > 1;
    }

Analog mit 'uc()' statt 'lc()' wenn man Grossbuchstaben will.

Achso, wenn in $font_name ein Pfad steht darf man den natuerlich nicht
pauschal umwandeln...

-dnh

--
Ceci n'est pas une .signature.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Christian Boltz]

Hallo David, hallo Leute,

Am Montag, 4. Juli 2005 02:09 schrieb David Haller:

> On Sun, 03 Jul 2005, Christian Boltz wrote:
> [..]
>
> >Vorschlag (Pseudocode):
> >
> >    Gehe durch alle Datenbankeinträge und führe folgendes aus:
> >        $font_count[font_name] ++;
> >    Anschließend gehe durch keys($font_count) und rufe für alle
> > Namen, bei denen  $font_count[font_name] > 1  ist, den Dupecheck
> > auf.
> >
> >Frage: Sind Keys in Perl case-sensitiv?   David?
>
> Ja. Laesst sich normalerweise aber durch ein normalisieren der
> Hash-Eintraege erschlagen:
>
>     $font_count{ lc($font_name) }++;
>
>     foreach( keys %font_count ) {
>         dupecheck($_) if $font_count{$_} > 1;
>     }
>
> Analog mit 'uc()' statt 'lc()' wenn man Grossbuchstaben will.

Sorry, Du hast da gerade etwas flahcs verstanden - in diesem Fall ist
die Unterscheidung nach Groß- und Kleinschreibung nicht unerwünscht,
sondern _erforderlich_.

Ein kurzer Test gestern hat komischerweise ergeben, dass die keys
case-insensitiv sind. Heute nochmal getestet [1]: ja, die keys sind
case-sensitiv. Frag mich nicht, wo ich mich gestern vertippt hatte...

@Ratti: Mit dieser Lösung könnten wir das blöde BINARY-Problem in MySQL
glatt umgehen...


Gruß

Christian Boltz

[1] perl -e '
    use strict; use warnings;
    my %test;
    $test{"foo"} = 5;
    $test{"Foo"} = 7;
    print $test{"foo"} . " - " . $test{"Foo"} . "\n";
    '

    Ergebnis:   5 - 7

--
Aber genauso können mir ja auch die Grünen leid tuen.
Da bin ich doch lieber blau ...
[Konrad Neitzel in suse-linux]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[David Haller]

Hallo,

Am Tue, 05 Jul 2005, Christian Boltz schrieb:

>Am Montag, 4. Juli 2005 02:09 schrieb David Haller:
>> On Sun, 03 Jul 2005, Christian Boltz wrote:
>> [..]
>> >Frage: Sind Keys in Perl case-sensitiv?   David?
>>
>> Ja. Laesst sich normalerweise aber durch ein normalisieren der
>> Hash-Eintraege erschlagen:
>>
>>     $font_count{ lc($font_name) }++;
>>
>>     foreach( keys %font_count ) {
>>         dupecheck($_) if $font_count{$_} > 1;
>>     }
>>
>> Analog mit 'uc()' statt 'lc()' wenn man Grossbuchstaben will.
>
>Sorry, Du hast da gerade etwas flahcs verstanden - in diesem Fall ist
>die Unterscheidung nach Groß- und Kleinschreibung nicht unerwünscht,
>sondern _erforderlich_.

Das habe ich ja auch mit beantwortet ;) Die Loesung in dem Fall ist aber
klar. Fuer den Fall, dass _nicht_ case-sensitiv erwuenscht gewesen
waere, habe ich obiges geschrieben :)

-dnh

--
Es ist noch keiner zu dumm gewesen um dumm zu sein. Aber wenn man
sich entscheidet was zu lernen, dann ist das schon recht klug.  [WoKo in dag°]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Joerg Rossdeutscher]

Moin,

(Optimierung des Dupechecks)

Am Sonntag, den 03.07.2005, 19:56 +0200 schrieb Christian Boltz:
> Vorschlag (Pseudocode):
>
>     Gehe durch alle Datenbankeinträge und führe folgendes aus:
>         $font_count[font_name] ++;
>     Anschließend gehe durch keys($font_count) und rufe für alle
> Namen,
>     bei denen  $font_count[font_name] > 1  ist, den Dupecheck auf.

Das ist eine gute Idee, und das sollten wir machen.

Ich möchte das aber erst nach dem Release anfassen, denn derzeit
funktioniert der Dupecheck, und wir haben gerade alles schön stabil.

Vorraussetzung wäre natürlich, dass man die als Nebeneffekt aufgetretene
Case-Sensitivität in der WebGUI hinbekommen.

Gruß,
Ratti

--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Joerg Rossdeutscher]

Moin,

Am Sonntag, den 03.07.2005, 19:56 +0200 schrieb Christian Boltz:
> > Der database assistant schickt zwei "ALTER" Statements bei
> > "--update-database", was bei "--phoenix" explizit enthalten ist.
>
> ... und das Suchfeld in der WebGUI ist plötzlich case-sensitiv.

Aye caramba.
Das sollte jetzt behoben sein, MySQL sucht jetzt nach

UCASE( font_name ) LIKE
'".strtoupper(mysql_escape_string($POST_find))."'

'nen Schönheitspreis gibts dafür nicht.

Gruß,
Ratti

--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Sonntag, 24. Juli 2005 14:36 schrieb Ratti:

> (Optimierung des Dupechecks)
>
> Am Sonntag, den 03.07.2005, 19:56 +0200 schrieb Christian Boltz:
> > Vorschlag (Pseudocode):
> >
> >     Gehe durch alle Datenbankeinträge und führe folgendes aus:
> >         $font_count[font_name] ++;
> >     Anschließend gehe durch keys($font_count) und rufe für alle
> > Namen,
> >     bei denen  $font_count[font_name] > 1  ist, den Dupecheck auf.
>
> Das ist eine gute Idee, und das sollten wir machen.
>
> Ich möchte das aber erst nach dem Release anfassen, denn derzeit
> funktioniert der Dupecheck, und wir haben gerade alles schön stabil.

Stimmt. Andererseits ist font_name gerade (nach der Änderung
überflüssigerweise) BINARY, was wieder einen Workaround in der WebGUI
nötig macht.

Da meine vorgeschlagene Änderung ja eher eine Kleinigkeit und recht
schnell zu testen ist, schlage ich vor, es noch vor dem Release zu
ändern und die ganzen Workarounds (BINARY für font_name, UCASE für die
Suche in der WebGUI) wieder zu entfernen. Insbesondere das BINARY
dürfte uns nämlich hinterher wieder ärgern ;-)

> Vorraussetzung wäre natürlich, dass man die als Nebeneffekt
> aufgetretene Case-Sensitivität in der WebGUI hinbekommen.

Das scheinst Du ja im Griff zu haben. Wenn auch die Lösung mit UCASE
nicht das schönste ist - sie funktioniert erstmal ;-)
Trotzdem: siehe oben.


Gruß

Christian Boltz
--
Und allen, die keinen Internetzugang haben bleibt nur übrig, bis zur
nächsten Ausgabe einer PC-Zeitung mit aktuellem Virenscanner zu warten.
                        [Hitradio AS gibt Tips zur ILOVEYOU-Bekämpfung]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Joerg Rossdeutscher]

Moin,

Moin,

Am Sonntag, den 24.07.2005, 18:28 +0200 schrieb Christian Boltz:
> Am Sonntag, 24. Juli 2005 14:36 schrieb Ratti:
> > (Optimierung des Dupechecks)
> > Am Sonntag, den 03.07.2005, 19:56 +0200 schrieb Christian Boltz:

> > >     Gehe durch alle Datenbankeinträge und führe folgendes aus:
> > >         $font_count[font_name] ++;
> > >     Anschließend gehe durch keys($font_count) und rufe für alle
> > > Namen,
> > >     bei denen  $font_count[font_name] > 1  ist, den Dupecheck auf.

> > Ich möchte das aber erst nach dem Release anfassen, denn derzeit
> > funktioniert der Dupecheck, und wir haben gerade alles schön stabil.
>
> Stimmt. Andererseits ist font_name gerade (nach der Änderung
> überflüssigerweise) BINARY, was wieder einen Workaround in der WebGUI
> nötig macht.
>
> Da meine vorgeschlagene Änderung ja eher eine Kleinigkeit und recht
> schnell zu testen ist, schlage ich vor, es noch vor dem Release zu
> ändern und die ganzen Workarounds (BINARY für font_name, UCASE für die
> Suche in der WebGUI) wieder zu entfernen. Insbesondere das BINARY
> dürfte uns nämlich hinterher wieder ärgern ;-)

Von "schnell" kann keine Rede sein, da steckt wie üblich mehr hinter -
zum Beispiel unterscheidet deine Methode nicht nach ttf/otf/ps, was dazu
führt, das jeweils der erste Font gegen die anderen getestet würde und
alle anderen Typen als "kein dupe" ignoriert, obwohl sie untereinander
wieder Dupes sein könnten... usw... usf...

Trotzdem. Das Argument mit "Binary erst rein und später wieder raus wird
uns ärgern" ist absolut gewichtig. Ich habe daher heute versucht, den
Code entsprechend umzubauen.

Da ich eine ganze Weile lang keine Zeit hatte, bin ich etwas "raus" aus
dem Code und hoffe, alles stimmig repariert zu haben. Denkt doch bitte
mal mit:

1. SQL-Datenbank
Jetzt:
`font_name` varchar(255) NOT NULL default ''
statt "varbinary"
*** BITTE MANUELL AUF EURE DATENBANKEN ANWENDEN!!!***

2. WebGUI
"UCASE" wieder raus

3. fontlinge_dupe geändert.


Ich hoffe, das war's?


Leider kann ich derzeit nicht ausführlich testen, ich habe noch eine zu
bearbeitende fontbase, die ich nicht löschen will, das problematische
MySQL ist noch nicht in Debian aufgeschlagen, deswegen ist das alles
wirklich *sehr* mit Vorsicht zu betrachten.

Christian, hast du vielleicht noch das Problem-Set von neulich, weswegen
wir die Umstellung überhaupt nur gemacht hatten? Kannst du das mal
testen, ob das jetzt immer noch sauber durchläuft?

...ich geh dann mal committen...

Gruß,
Ratti


--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Samstag, 6. August 2005 10:45 schrieb Ratti:

> Am Sonntag, den 24.07.2005, 18:28 +0200 schrieb Christian Boltz:
> > Am Sonntag, 24. Juli 2005 14:36 schrieb Ratti:
> > > (Optimierung des Dupechecks)
> > >
> > > Am Sonntag, den 03.07.2005, 19:56 +0200 schrieb Christian Boltz:
> > > >     Gehe durch alle Datenbankeinträge und führe folgendes aus:
> > > >         $font_count[font_name] ++;
> > > >     Anschließend gehe durch keys($font_count) und rufe für alle
> > > > Namen,
> > > >     bei denen  $font_count[font_name] > 1  ist, den Dupecheck
> > > > auf.
> > >
> > > Ich möchte das aber erst nach dem Release anfassen, denn derzeit
> > > funktioniert der Dupecheck, und wir haben gerade alles schön
> > > stabil.
> >
> > Stimmt. Andererseits ist font_name gerade (nach der Änderung
> > überflüssigerweise) BINARY, was wieder einen Workaround in der
> > WebGUI nötig macht.
> >
> > Da meine vorgeschlagene Änderung ja eher eine Kleinigkeit und recht
> > schnell zu testen ist, schlage ich vor, es noch vor dem Release zu
> > ändern und die ganzen Workarounds (BINARY für font_name, UCASE für
> > die Suche in der WebGUI) wieder zu entfernen. Insbesondere das
> > BINARY dürfte uns nämlich hinterher wieder ärgern ;-)
>
> Von "schnell" kann keine Rede sein, da steckt wie üblich mehr hinter
> - zum Beispiel unterscheidet deine Methode nicht nach ttf/otf/ps, was

Stimmt, dafür ist die zusätzliche Schleife außenrum fällig.

> dazu führt, das jeweils der erste Font gegen die anderen getestet
> würde und alle anderen Typen als "kein dupe" ignoriert, obwohl sie
> untereinander wieder Dupes sein könnten... usw... usf...

Nö, ich habe explizit "für alle Namen" (nicht: "erste passende ID")
geschrieben ;-)

> Trotzdem. Das Argument mit "Binary erst rein und später wieder raus
> wird uns ärgern" ist absolut gewichtig.

Jepp.

> Ich habe daher heute versucht, den Code entsprechend umzubauen.

Das ist Dir (zumindest meinem Kurztest zufolge) auch gelungen ;-)

> Da ich eine ganze Weile lang keine Zeit hatte, bin ich etwas "raus"
> aus dem Code und hoffe, alles stimmig repariert zu haben. Denkt doch
> bitte mal mit:
>
> 1. SQL-Datenbank
> Jetzt:
> `font_name` varchar(255) NOT NULL default ''
> statt "varbinary"
> *** BITTE MANUELL AUF EURE DATENBANKEN ANWENDEN!!!***

Bei neuem MySQL:
ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL

> 2. WebGUI
> "UCASE" wieder raus

Funktioniert weiterhin wie gewünscht.

> 3. fontlinge_dupe geändert.

Funktioniert. (Und wieder was gelernt - DISTINCT kannte ich noch nicht.)

Bleibt noch der übliche Kleinkram...

Zwecks Absicherung gegen eine manuell und bösartig geänderte DB:

    $sth = $dbh->prepare("SELECT font_name, font_id FROM fonts WHERE
                                             BINARY font_datatype=?");
    $sth->execute($type_row->{"font_datatype"});

Mit dieser Methode übernimmt MySQL freundlicherweise das Quoting des
font_datatype und verhindert zuverlässig mögliche SQL-Injections ;-)
Done.

Noch ein Verbesserungsvorschlag (noch nicht umgesetzt):
dupecheck() sucht anhand der Font-ID Name und Datentyp aus der DB, aber
das haben wir eigentlich schon in der Schleife verfügbar.
Die optimierte Variante wäre, dupecheck ($fontname, $font_datatype)
statt dupecheck($id) aufzurufen - das würde die erste SQL-Query
überflüsig machen. Auch $fontcount_id würde dadurch überflüssig.
Meinungen?

> Ich hoffe, das war's?

Nö.
fontlinge_database_assistant --update-database  hast Du vergessen ;-)
(für font_path muss die Änderung auf "varbinary" wohl drinbleiben,
oder?)

BTW: die ALTER-Befehle wurden auch bei --check ausgeführt und nicht nur
bei --update-database. Fixed.
(--check überprüft die DB diesbezüglich nicht, aber da ja sowieso neue
Indizies angelegt werden, wird wohl jeder User --update-database
ausführen.)

BTW2: --check gibt bei fehlgeschlagener MySQL-Verbindung das Passwort im
Klartext aus:
    I could not even connect to the database with this account.
    Make sure MySql is prepared for user "fontlinge" and password
    "geheim" or change ~/.fontlinge to a valid account.
Unschön - wollen wir das ändern?

> Leider kann ich derzeit nicht ausführlich testen, ich habe noch eine
> zu bearbeitende fontbase, die ich nicht löschen will, das

man testuser; man another-database ;-)

> problematische MySQL ist noch nicht in Debian aufgeschlagen, deswegen
> ist das alles wirklich *sehr* mit Vorsicht zu betrachten.
>
> Christian, hast du vielleicht noch das Problem-Set von neulich,

Natürlich[tm] ;-)

> weswegen wir die Umstellung überhaupt nur gemacht hatten? Kannst du
> das mal testen, ob das jetzt immer noch sauber durchläuft?
>
> ...ich geh dann mal committen...

Aktueller Stand nach   cvs update   und Zurückändern der Datenbank:

# fontlinge_dupe -v --really
DEL  | .../crashbase/code3/Code39_Regular.ttf | Code39 Regular | done |
keep | .../crashbase/code3/Code39_Regular(2). | Code39 Regular | keep |

DEL  | .../crashbase/codex/codex.ttf          | codex          | done |
DEL  | .../crashbase/codex/codex(4).ttf       | codex          | done |
DEL  | .../crashbase/codex/codex(3).ttf       | codex          | done |
keep | .../crashbase/codex/codex(2).ttf       | codex          | keep |

DEL  | .../crashbase/code3/CODE3X.ttf         | CODE3X         | done |
DEL  | .../crashbase/code3/CODE3X(3).ttf      | CODE3X         | done |
keep | .../crashbase/code3/CODE3X(2).ttf      | CODE3X         | keep |

Sieht gut aus ;-)


Gruß

Christian Boltz
--
2.-5.9.2005: Weinfest in Insheim
Bei der Landjugend: Liquid, AH-Band und Deafen Goblins
Mehr Infos: www.Landjugend-Insheim.de


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

[Joerg Rossdeutscher]

Moin,

Am Sonntag, den 07.08.2005, 21:49 +0200 schrieb Christian Boltz:
> Am Samstag, 6. August 2005 10:45 schrieb Ratti:
> > Am Sonntag, den 24.07.2005, 18:28 +0200 schrieb Christian Boltz:
> > > Am Sonntag, 24. Juli 2005 14:36 schrieb Ratti:
> > > > (Optimierung des Dupechecks)

[Bestätigung, das alles erstmal gut aussieht]

Juhu.

> > Da ich eine ganze Weile lang keine Zeit hatte, bin ich etwas "raus"
> > aus dem Code und hoffe, alles stimmig repariert zu haben. Denkt doch
> > bitte mal mit:
> >
> > 1. SQL-Datenbank
> > Jetzt:
> > `font_name` varchar(255) NOT NULL default ''
> > statt "varbinary"
> > *** BITTE MANUELL AUF EURE DATENBANKEN ANWENDEN!!!***
>
> Bei neuem MySQL:
> ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL

Ich erinnere mich an das "swedish", aber das kanns ja irgendwie nicht
sein. Gibt es da nicht was Allgemeineres?

Ich möchte dich bitten, dass Du die MySQL-Änderung durchführst. Mit
meinem MySQL in der chroot ist das alles sehr unhandlich.
Ich habe mir dabei vor einiger Zeit etliche Gigs an Daten gelöscht
(Platte war mit --bind ein zweites mal in die chroot gemountet, und ich
wollte bloß die chroot-Umgebung nach Gebrauch wieder löschen... rumms,
hat rm -rf /disk2/chroot rekursiv ganz /disk2 geplättet...)

Oder wir warten, bis das aktuelle MySQL in Debian sid aufschlägt, aber
das kann lange dauern, weil Debian gerade den ABI-Wechsel auf gcc 4.2
durchläuft und deswegen fast alles klemmt.


> Noch ein Verbesserungsvorschlag (noch nicht umgesetzt):
> dupecheck() sucht anhand der Font-ID Name und Datentyp aus der DB, aber
> das haben wir eigentlich schon in der Schleife verfügbar.
> Die optimierte Variante wäre, dupecheck ($fontname, $font_datatype)
> statt dupecheck($id) aufzurufen - das würde die erste SQL-Query
> überflüsig machen. Auch $fontcount_id würde dadurch überflüssig.
> Meinungen?

Der Einwand ist korrekt.
Ich möchte am jetzigen Verfahren festhalten, weil es erweiterungsfähiger
ist. Wenn man die ID übergibt, sucht man spezifisch Dupes zu DIESEM
Font. Wenn man nur den Namen übergibt, wird aus der ganzen Gruppe
gleichnamiger Fonts "einer" ausgewählt. Der Bezug zum Aufruf geht dabei
verloren, es werden halt alle $name geprüft.

Ich habe noch nichts spezielles dazu im Kopf, aber zum Beispiel bei der
verschiedenen Behandlung von neu dazugekommenen und bereits vorhandenen
Fonts könnte es nochmal interessant werden, einen bestimmten Font
anzufragen und den bevorzugt zu behalten oder löschen.

Das ist in der jetzigen Form noch nicht möglich, aber das Unterprogramm
könnte in Zukunft dahingehend erweitert werden.

>
> > Ich hoffe, das war's?
>
> Nö.
> fontlinge_database_assistant --update-database  hast Du vergessen ;-)
> (für font_path muss die Änderung auf "varbinary" wohl drinbleiben,
> oder?)

Ja, ich glaube. Ich weiss den Grund nciht mehr, aber das hatten wir
schon mal diskutiert.

So. Ich habe jetzt was geändert, leider vergessen vorher upzudaten, habe
einen Konflikt verursacht, meins weggeworfen und deins ausgecheckt.

Vorher stand da:
execute_mysql_user( "ALTER TABLE $database.fonts CHANGE font_name font_name varchar(255) not null" , () );
execute_mysql_user( "ALTER TABLE $database.fonts CHANGE font_path
font_path varbinary(255) not null" , () );

Jetzt ist font_name verschwunden, es gibt nur noch:
execute_mysql_user( "ALTER TABLE $database.fonts CHANGE font_path
font_path varbinary(255) not null" , () );

Das ist richtig, weil die Datenbank gar nicht mehr verändert wird,
richtig?


> BTW2: --check gibt bei fehlgeschlagener MySQL-Verbindung das Passwort im
> Klartext aus:
>     I could not even connect to the database with this account.
>     Make sure MySql is prepared for user "fontlinge" and password
>     "geheim" or change ~/.fontlinge to a valid account.
> Unschön - wollen wir das ändern?

Das ist natürlich ein bisschen Augenwischerei, weil die Configdatei
ohnehin offenliegt. Aber nehmen wir's einfach raus. Done.

> > Leider kann ich derzeit nicht ausführlich testen, ich habe noch eine
> > zu bearbeitende fontbase, die ich nicht löschen will, das
>
> man testuser; man another-database ;-)

Ne, falls die CDU die Wahl gewinnt, zahlen wir Steuern pro Account statt
pro Kopf. Ich bin schon dabei, mein ganzes System so zu patchen, dass
alles als user "nobody" und group "caimanislands" läuft. :-)

> > problematische MySQL ist noch nicht in Debian aufgeschlagen, deswegen
> > ist das alles wirklich *sehr* mit Vorsicht zu betrachten.
> >
> > Christian, hast du vielleicht noch das Problem-Set von neulich,
>
> Natürlich[tm] ;-)

> DEL  | .../crashbase/code3/CODE3X.ttf         | CODE3X         | done |
> DEL  | .../crashbase/code3/CODE3X(3).ttf      | CODE3X         | done |
> keep | .../crashbase/code3/CODE3X(2).ttf      | CODE3X         | keep |

Uff. Was würde ich ohne Dich tun. :-)

...ich glaube, es wird mal wieder Zeit für eine meiner berüchtigten "Was
ist eigentlich noch offen?"-Mails.
Das sieht doch alles sehr gut aus.


Gruß,
Ratti

--
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

[Christian Boltz]

Hallo Ratti, hallo Leute,

Am Montag, 8. August 2005 21:58 schrieb Ratti:

> Am Sonntag, den 07.08.2005, 21:49 +0200 schrieb Christian Boltz:
> > Am Samstag, 6. August 2005 10:45 schrieb Ratti:
> > > Am Sonntag, den 24.07.2005, 18:28 +0200 schrieb Christian Boltz:
> > > > Am Sonntag, 24. Juli 2005 14:36 schrieb Ratti:
> > > > > (Optimierung des Dupechecks)
> > > Da ich eine ganze Weile lang keine Zeit hatte, bin ich etwas
> > > "raus" aus dem Code und hoffe, alles stimmig repariert zu haben.
> > > Denkt doch bitte mal mit:
> > >
> > > 1. SQL-Datenbank
> > > Jetzt:
> > > `font_name` varchar(255) NOT NULL default ''
> > > statt "varbinary"
> > > *** BITTE MANUELL AUF EURE DATENBANKEN ANWENDEN!!!***
> >
> > Bei neuem MySQL:
> > ALTER TABLE `fonts` CHANGE `font_name` `font_name` VARCHAR( 255 )
> > CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL
>
> Ich erinnere mich an das "swedish", aber das kanns ja irgendwie nicht
> sein. Gibt es da nicht was Allgemeineres?

Schon, aber swedish ist der default, und zwar:
- wenn man eine bestehende Datenbank in MySQL 4.1 übernimmt und
- wenn man einen "alten" SQL-Dump ohne Zeichensatzangabe in MySQL 4.1
  importiert

Überlies es einfach - alles außer swedish bedeutet zusätzliche Arbeit
ohne Nutzwert.

BTW: Wo kommt eigentlich MySQL her? Merkst Du was? *g*

> Ich möchte dich bitten, dass Du die MySQL-Änderung durchführst. Mit
> meinem MySQL in der chroot ist das alles sehr unhandlich.
> Ich habe mir dabei vor einiger Zeit etliche Gigs an Daten gelöscht
> (Platte war mit --bind ein zweites mal in die chroot gemountet, und
> ich wollte bloß die chroot-Umgebung nach Gebrauch wieder löschen...
> rumms, hat rm -rf /disk2/chroot rekursiv ganz /disk2 geplättet...)

*aua*

> Oder wir warten, bis das aktuelle MySQL in Debian sid aufschlägt,
> aber das kann lange dauern, weil Debian gerade den ABI-Wechsel auf
> gcc 4.2 durchläuft und deswegen fast alles klemmt.

Teste doch zwischendurch openSUSE 10.0 beta - das dürfte einige
aktuellere Pakete als Debian enthalten ;-)

> > Noch ein Verbesserungsvorschlag (noch nicht umgesetzt):
> > dupecheck() sucht anhand der Font-ID Name und Datentyp aus der DB,
> > aber das haben wir eigentlich schon in der Schleife verfügbar.
> > Die optimierte Variante wäre, dupecheck ($fontname, $font_datatype)
> > statt dupecheck($id) aufzurufen - das würde die erste SQL-Query
> > überflüsig machen. Auch $fontcount_id würde dadurch überflüssig.
> > Meinungen?
>
> Der Einwand ist korrekt.
> Ich möchte am jetzigen Verfahren festhalten, weil es
> erweiterungsfähiger ist. Wenn man die ID übergibt, sucht man
> spezifisch Dupes zu DIESEM Font. Wenn man nur den Namen übergibt,
> wird aus der ganzen Gruppe gleichnamiger Fonts "einer" ausgewählt.
> Der Bezug zum Aufruf geht dabei verloren, es werden halt alle $name
> geprüft.
>
> Ich habe noch nichts spezielles dazu im Kopf, aber zum Beispiel bei
> der verschiedenen Behandlung von neu dazugekommenen und bereits
> vorhandenen Fonts könnte es nochmal interessant werden, einen
> bestimmten Font anzufragen und den bevorzugt zu behalten oder
> löschen.

Du meinst sowas wie   fontlinge-base --copy --dupe   ? ;-)

> Das ist in der jetzigen Form noch nicht möglich, aber das
> Unterprogramm könnte in Zukunft dahingehend erweitert werden.

OK, gutes Argument.

> > > Ich hoffe, das war's?
> >
> > Nö.
> > fontlinge_database_assistant --update-database  hast Du vergessen
> > ;-) (für font_path muss die Änderung auf "varbinary" wohl
> > drinbleiben, oder?)
>
> Ja, ich glaube. Ich weiss den Grund nciht mehr, aber das hatten wir
> schon mal diskutiert.

Jepp - Grund ist, dass das Dateisystem unter Linux case-sensitiv ist.
(Für eine Fontbase auf fat32 müsste man strenggenommen die
Felddefinition ändern ;-)

> So. Ich habe jetzt was geändert, leider vergessen vorher upzudaten,
> habe einen Konflikt verursacht, meins weggeworfen und deins
> ausgecheckt.

Hast Du so wenig Vertrauen in Deine Änderungen? ;-)

[...]
> Jetzt ist font_name verschwunden, es gibt nur noch:
> execute_mysql_user( "ALTER TABLE $database.fonts CHANGE font_path
> font_path varbinary(255) not null" , () );
>
> Das ist richtig, weil die Datenbank gar nicht mehr verändert wird,
> richtig?

Jepp. font_path als varbinary ist der aktuelle Stand.

User älterer Fontlinge-Versionen brauchen den ALTER-Befehl aber, weil es
damals[tm] noch "varchar binary" war.

> > BTW2: --check gibt bei fehlgeschlagener MySQL-Verbindung das
> > Passwort im Klartext aus:
> >     I could not even connect to the database with this account.
> >     Make sure MySql is prepared for user "fontlinge" and password
> >     "geheim" or change ~/.fontlinge to a valid account.
> > Unschön - wollen wir das ändern?
>
> Das ist natürlich ein bisschen Augenwischerei, weil die Configdatei
> ohnehin offenliegt.

Klar, aber die öffnet man nicht gerade im Editor, wenn jemand über die
Schulter schaut.

> Aber nehmen wir's einfach raus. Done.

Gut ;-)

> > > Leider kann ich derzeit nicht ausführlich testen, ich habe noch
> > > eine zu bearbeitende fontbase, die ich nicht löschen will, das
> >
> > man testuser; man another-database ;-)
>
> Ne, falls die CDU die Wahl gewinnt, zahlen wir Steuern pro Account
> statt pro Kopf.

Das dürfte für mich teuer werden ;-)
Meine gespaltene Persönlichkeit arbeitet mit den Usern cb (Hauptuser),
test (für non-trusted Programme usw.), compile (hat als einziger
Schreibrecht im RPM-BuildRoot), cvs (per ssh @localhost) und derzeit
auch beta1 (ein "sauberer", neu angelegter User für die SUSE beta).

> Ich bin schon dabei, mein ganzes System so zu patchen, dass alles als
> user "nobody" und group "caimanislands" läuft. :-)

*LoL*

> > > problematische MySQL ist noch nicht in Debian aufgeschlagen,
> > > deswegen ist das alles wirklich *sehr* mit Vorsicht zu
> > > betrachten.
> > >
> > > Christian, hast du vielleicht noch das Problem-Set von neulich,
> >
> > Natürlich[tm] ;-)
[...]
> Uff. Was würde ich ohne Dich tun. :-)
>
> ...ich glaube, es wird mal wieder Zeit für eine meiner berüchtigten
> "Was ist eigentlich noch offen?"-Mails.
> Das sieht doch alles sehr gut aus.

Jepp ;-)


Gruß

Christian Boltz
--
2.-5.9.2005: Weinfest in Insheim
Bei der Landjugend: Liquid, AH-Band und Deafen Goblins
Mehr Infos: www.Landjugend-Insheim.de


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel