Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 13. Januar 2011 19:05

piratos
Gast

[GELÖST] [GELÖST] Adodb Lite

Ich hatte nunmehr vor drei Jahren Email - Kontakt mit dem Autoren von Adodb Lite, der damals meinte Lite wäre nicht tot, er hätte sich aber ein heruntergekommenes Haus gekauft das er vollständig restaurieren müsste aber er würde in Kürze wieder antreten.

Das ist nicht der Fall und wie man sehen kann (in seinem Blog) ist sein Haus auch noch nicht fertig.

Ein Forum zur Lite Version ist komplett tot und auf SF  sind die letzten Beiträge 3..4 Jahre alt und somit  kann eines klar festgestellt werden - man muss nicht länger auf Tote warten.

Die letzte Lite Version ist   ADOdb Lite Version 1.42 - January 11, 2007 und die ist 100% PHP 4 und hat unter aktuellen PHP Versionen so seine Macken, die man auf einfache Art nur weg bekommt, wenn man  alle Fehlermeldungen unterdrückt.

Adodb die große Version ist jetzt bei 5.11 vom  5 May 2010 angekommen, eigentlich wäre nun wieder eine neue fällig, allerdings haben Layersysteme enorme Konkurrenz bekommen mit der PHP PDO: Technik.

Und tatsächlich auch für Mysql wurde nach Jahren noch Fehler gefunden und gefixt.

Adodb hat jedoch einen enormen Nachteil - es unterstützt massig DB Systeme.

Der Aufwand für Adodb ist deshalb enorm hoch bei der Pflege und kein Schwein benötigt diese Vielzahl von DB Möglichkeiten.

Es wäre also für Systeme wie CMSMS an der Zeit sich ernsthafte Gedanken darüber zu machen, welchen DB Treiber man denn nun einsetzen will .

Belässt man das so ist das Aus absehbar.

#2 13. Januar 2011 19:18

dc2
arbeitet mit CMS/ms
Registriert: 26. November 2010
Beiträge: 140
Webseite

Re: [GELÖST] [GELÖST] Adodb Lite

Ich versteh auch ehrlich gesagt nicht, warum CMSMS jetzt tausend DBS unterstützen soll.
In meinen Augen wäre es tausendmal sinnvoller, die Vorteile eines weit verbreiteten DBS wie etwa MySQL effektiv auszunutzen (Stichwort auto_increment statt Sequenz-Tabellen und viele andere Sachen), anstatt mit einer Krücke wie ADOdb (Lite) herumzurumpeln.

Offline

#3 13. Januar 2011 19:39

piratos
Gast

Re: [GELÖST] [GELÖST] Adodb Lite

dc2 schrieb:

Ich versteh auch ehrlich gesagt nicht, warum CMSMS jetzt tausend DBS unterstützen soll.

Wenn die das denn mal machen würden . big_smile
Lediglich Mysql läuft richtig.
Man hat wohl bei CMSMS übersehen, das Layersysteme nur rudimentäre Dinge erledigen nicht aber SQL Abfragen von X nach Y Zielsystem umarbeiten.

#4 14. Januar 2011 08:46

cyberman
Moderator
Ort: Dohna / Sachsen
Registriert: 13. September 2010
Beiträge: 6.879
Webseite

Re: [GELÖST] [GELÖST] Adodb Lite

Liesse sich da nicht eine Art PDO/MySQL-Wrapper schreiben, den man CMSms anstatt des original adodb unterschieben kann?

Zumindest vom Aufwand her waere es geringer, als CMSms komplett auf mysql umzuschreiben - mit einem weiteren Fork waere niemandem geholfen und das soll auch nicht Thema dieses Forums sein.

Und performanceseitig sollte ja dann auch etwas "haengen" bleiben ...


1. Wie bekomme ich hier schnelle Hilfe?
2. HowTo: Fehlersuche bei CMS/ms
---
„First they ignore you, then they laugh at you, then they fight you, then you win.“ Mahatma Ghandi

Offline

#5 14. Januar 2011 13:06

piratos
Gast

Re: [GELÖST] [GELÖST] Adodb Lite

cyberman schrieb:

Liesse sich da nicht eine Art PDO/MySQL-Wrapper schreiben, den man CMSms anstatt des original adodb unterschieben kann?

Zumindest vom Aufwand her waere es geringer, als CMSms komplett auf mysql umzuschreiben - mit einem weiteren Fork waere niemandem geholfen und das soll auch nicht Thema dieses Forums sein.

Und performanceseitig sollte ja dann auch etwas "haengen" bleiben ...

Ja das ist dein Traum , kann man sicher machen, was dann noch an Zusatzperformance hängen bleiben würde wäre allerdings weniger und ich hätte meine Zweifel ob sich das lohnen würde.
Das kann man nur ermitteln wenn man es einmal realisiert und vergleicht.

Was hier noch nicht so richtig verstanden wurde - die gesamten SQL-Abfragen unter CMSMS sind den Zwängen von Adodb gefolgt.
Adodb formuliert nun mal nicht normale Abfragen um, damit die aber von allen unterstützten Systemen auch gefressen werden sind sie bei CMSMS auf Low Level gehalten.
Im Klartext - die entsprechen in etwas dem Niveau der Leistungsfähigkeit von Mysql 3.XX und nicht von den aktuellen Mysql - Versionen.
In vielen Fällen stört es nicht weiter, aber es gibt einige Punkte die aktuell dazu führen das man  Mengen von Abfragen hat die in Schleifen ausgeführt werden und zwischendurch mit PHP aufbereitet werden - obwohl man das mit einer einzigen Abfrage unter Mysql erledigen könnte.
Würde man eine solche Abfrage aber so einsetzen, würden andere DB's nichts damit anfangen können.

Ich glaube auf Grund der aktuellen Situation bei CMSMS nicht das eine solche DB Klasse jemals zum Einsatz kommen wird.
Für Version 2 wurde ja ebenfalls der Einsatz von Adodb angekündigt.
Ob die Version 2 jemals kommen wird oder erst zu Zeiten von PHP 7  oder wenn Ted Kulop kurz vor der Rente steht das weiss offenbar niemand.

Es wäre also mehr eine Entscheidungslinie für die V2 - Linie:

1. Welche DB's sollen unterstützt werden ?
2.Ist es nur Mysql dann würde sich der Einsatz von adodb vollständig erübrigen, sind es nur solche die auch von PDO unterstützt werden, hätte sich adodb auch erledigt.
3. Man muss sich im klaren sein, das für jedes DB - Zielsystem teils individuelle Tabellenstrukturen wie auch Abfragen zu machen sind um die jeweils mögliche Power optimal auszunutzen - genau das hat man bei CMSMS nie gemacht und verwendet damit  Low-Level Sql.
4. Man muss bei Mysql auf den Typ InnoDB umstellen (wird demnächst Standard unter Mysql) bzw. analoge Typen bei anderen unterstützten DB's - und da wird es schon schiwerig.

Es macht wenig Sinn eine Klasse zu schreiben welche zum Austausch geeignet wäre, wenn die Zielsetzungen für die künftigen Versionen noch nicht wirklich klar sind.

#6 15. Januar 2011 07:49

cyberman
Moderator
Ort: Dohna / Sachsen
Registriert: 13. September 2010
Beiträge: 6.879
Webseite

Re: [GELÖST] [GELÖST] Adodb Lite

piratos schrieb:

Es wäre also mehr eine Entscheidungslinie für die V2 - Linie:

...

Es macht wenig Sinn eine Klasse zu schreiben welche zum Austausch geeignet wäre, wenn die Zielsetzungen für die künftigen Versionen noch nicht wirklich klar sind.

Da es Ted mit der V2 offensichtlich nicht wie gewünscht hinbekommt, da er den Job im wesentlichen allein macht, hätte ich schon lange auf einen "Smart Move" umgeschwenkt, also die 1er Version nach und nach in eine 2er übergehen lassen.

Wie gesagt - bei mein Vorschlag bin ich nur von MySQL ausgegangen ... SQLite ist schon vor längerem rausgeflogen, Postgres wird von CG nicht unterstützt - ergo, es sollte nur MySQL unterstützt werden.

Würde für einen Smart Move auch insoweit Sinn machen, als das die Kompatibilität für die Module zunächst erhalten blieben, als wenn es plötzlich MySQL nativ wäre.


1. Wie bekomme ich hier schnelle Hilfe?
2. HowTo: Fehlersuche bei CMS/ms
---
„First they ignore you, then they laugh at you, then they fight you, then you win.“ Mahatma Ghandi

Offline

#7 15. Januar 2011 12:41

piratos
Gast

Re: [GELÖST] [GELÖST] Adodb Lite

SmartMove scheitert schon allein daran das die bisherige Programmierung von CMSMS bis aktuell was E_STRICT betrifft sehr zu wünschen übrig lässt.
Qualitäts-Progger haben damit reichlich Schwierigkeiten wenn sie ganz tief eingreifen.
Beispiel:
$result = &$db->Execute($query);
führt wenn e_strict wirksam ist zu das:
Strict Standards: Only variables should be assigned by reference in /var/www/cmsms/lib/page.functions.php on line 565

Solche Konstrukte sind falsch - findet man aber zu hunderten.

Und CMSMS verwendet statt einheitlich Ergebnissets (fertig aufbereitete Ergebnisse) auch gemischt Resultsets (die müssen noch aufbereitet werden)

Das bedeutet - man müsste auch diese Funktionen nachbilden die da benutzt werden.

Das wäre ein Verdrehen von PDO in's Groteske, es würde so etwas dabei heraus kommen wie Adodb groß und alles in eine Klasse gepackt.

Zudem müsste man auch einige Konzeptionsfehler  und Programmierfehler ausmerzen wie  diese hier:

/**
    * Disconnect from the database.
    *
    * @final
    * @internal
    * @access private
    */
    public function dbshutdown()
    {
        if (isset($this->db))
        {
            $db =& $this->db;
            if ($db->IsConnected())
                $db->Close();
        }
    }

was dazu führt das eine Einstellung von pconnect keinerlei Wirkung hat, da diese Funktion als Shutdownfunktion registriert ist und somit die Verbindung generell kappt (Ja das ist ein Programmierfehler - man hätte vor der Registrierung mal nachsehen müssen was die config dazu sagt.).

Im Klartext gesagt

es ist meiner Meinung nach absolut sinnlos diesbezüglich etwas zu machen , da bei der Verwendung von Adodb unter CMSMS keine Generallinie verfolgt wird.
Es werden Adodb - Bestandteile geladen die nie in der Core benutzt werden (wie transaction) können, da man überhaupt keine Transaktionsfähige Tabellen (InnoDB) einsetzt - aber es könnte damit ein Modulschreiber auf die Idee gekommen sein das mal zu probieren.

#8 16. Januar 2011 22:29

cyberman
Moderator
Ort: Dohna / Sachsen
Registriert: 13. September 2010
Beiträge: 6.879
Webseite

Re: [GELÖST] [GELÖST] Adodb Lite

piratos schrieb:

was dazu führt das eine Einstellung von pconnect keinerlei Wirkung hat, da diese Funktion als Shutdownfunktion registriert ist und somit die Verbindung generell kappt (Ja das ist ein Programmierfehler - man hätte vor der Registrierung mal nachsehen müssen was die config dazu sagt.).

Sprichst du hier von adodb, adodb lite oder cmsms?


1. Wie bekomme ich hier schnelle Hilfe?
2. HowTo: Fehlersuche bei CMS/ms
---
„First they ignore you, then they laugh at you, then they fight you, then you win.“ Mahatma Ghandi

Offline

#9 17. Januar 2011 23:52

piratos
Gast

Re: [GELÖST] [GELÖST] Adodb Lite

Da spreche ich von CMSMS  - der Codeauszug stammt von CMSMS, was natürlich sinnig ist  yikes  wenn man diese Einstellung dabei nicht checkt:

#Use persistent connections?  They're generally faster, but not all hosts
#allow them.
$config['persistent_db_conn'] = false;