Login with email address? (General)

by Stephan Sander, Monday, March 01, 2021, 07:35 (1124 days ago)

Hi,
I'm combining this little forum at my website.
To make it easier for our members I'd like to keep two user accounts synchronized.

Setting the username to the email address would works, but in this case the email address is shown at all postings which is not quite helpful.

Is it possible to login at my little forum with email address instead of username?
I've tried to change username to email address within login.inc.php but without success.

Any suggestions are welcome.

cu
-Stephan-

Avatar

Login with email address?

by Micha ⌂, Monday, March 01, 2021, 08:22 (1123 days ago) @ Stephan Sander

Hello,

the SQL statement selects the users by the names - see where-condition at the end of this statement:

SELECT user_id, user_name, user_pw, user_type, 
UNIX_TIMESTAMP(last_login) AS last_login, 
UNIX_TIMESTAMP(last_logout) AS last_logout, 
thread_order, user_view, sidebar, fold_threads, 
thread_display, category_selection, auto_login_code, 
activate_code, LANGUAGE, time_zone, time_difference, 
theme, tou_accepted, dps_accepted 
FROM ".$db_settings['userdata_table']." 
 
WHERE 
LOWER(user_name) = '". mysqli_real_escape_string($connid, my_strtolower($request_username, $lang['charset'])) ."'") 

Maybe(!), it is possible to add a further condition to the email field user_email, i.e.,

WHERE 
LOWER(user_name) = '". mysqli_real_escape_string($connid, my_strtolower($request_username, $lang['charset'])) ."'") 
OR 
lower(user_email) = '". mysqli_real_escape_string($connid, my_strtolower($request_username, $lang['charset'])) ."'") 

Please note: There is a negative side effect (security issue). Currently, the email filed is NOT a unique field. Different users can have identical mail addresses. This is critical, because the email-password combination is not bijective.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Login with email address?

by Stephan Sander, Monday, March 01, 2021, 09:21 (1123 days ago) @ Micha

Awesome! Thanks for the super fast reply.

My thoughts were way too complicated :)
A quick test looks promising.

The accounts on my site will automatically be inserted into the forums database. And on that leading system the email address is unique.
But I'll keep that in mind.


This forum is perfect for my purpose.
Simple, small and easy to be customized. And with great support :-D

cu
-Stephan-

Avatar

Login with email address?

by Micha ⌂, Monday, March 01, 2021, 09:44 (1123 days ago) @ Stephan Sander

Hello Stephan,

The accounts on my site will automatically be inserted into the forums database. And on that leading system the email address is unique.

If so, I would suggest to set the email column of the user table to unique. If, for what reason ever, your check fails, the data integration is preserved by the DBMS.

kind reagrds
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Login with email address?

by Micha ⌂, Monday, March 01, 2021, 10:13 (1123 days ago) @ Stephan Sander

Hello,

FYI: I checked the behavior of the forum software. Mylittelforum also checks the email-address during the registration procedure. If the email is already used, an error is thrown, i.e.,
There is already a user with this e-mail address .

HOWEVER, if a user is registered, it is possible to change the email address. In this case, the new mail address is surprisingly not checked against existing ones. I will open a ticket because it is inconsistent.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Login with email address?

by Auge ⌂, Monday, March 01, 2021, 11:39 (1123 days ago) @ Micha

Hello

FYI: I checked the behavior of the forum software. Mylittelforum also checks the email-address during the registration procedure. If the email is already used, an error is thrown, i.e.,
There is already a user with this e-mail address.

I encountered this a few times in my testing forum and was therefore a bit surprised about the contrary statement in your previous posting.

HOWEVER, if a user is registered, it is possible to change the email address. In this case, the new mail address is surprisingly not checked against existing ones. I will open a ticket because it is inconsistent.

You are absolutely right. This is an error.

By the way. I saw your several commitments to the repo of the last few days. Great work! Thank you.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Login with email address?

by Micha ⌂, Monday, March 01, 2021, 17:22 (1123 days ago) @ Auge

Hello Auge,

You are absolutely right. This is an error.

Okay, we should fix it in the php script, but how should we handle existing collisions (if we add unique to the DB column)?

By the way. I saw your several commitments to the repo of the last few days. Great work!

Thank you. I'm currently not sure, how we should handle the @-syntax. Any suggestions?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Login with email address?

by Auge ⌂, Monday, March 01, 2021, 21:59 (1123 days ago) @ Micha

Hello

You are absolutely right. This is an error.


Okay, we should fix it in the php script, but how should we handle existing collisions (if we add unique to the DB column)?

Good question. I've no idea at the moment. The problem I see is, that the update script, started by the forum admin/operator, could run into this error but any forum user can use a doublette of an e-mail-address. The update would fail and the cause could only get solved by the doublette-using user. O.k., also the forum admin/operator could solve such problems, but I'm not convinced that it would be a good idea to enforce the forum admin/operator to edit one or more user profiles. Especially when it comes to changing the e-mail-address that is a basic necessity for handling of notifications and user data changes (password, e-mail-address (this is, where it begins to spinning round in circles)).

Additionally, spoken as a user, I wouldn't like it if someone edits my user data profile without prior information and explanatory statement about the action.

On the other hand a forum operator could uncover socket puppets. ;-)

By the way. I saw your several commitments to the repo of the last few days. Great work!


Thank you. I'm currently not sure, how we should handle the @-syntax. Any suggestions?

Most (or maybe all) occurences in the code that I remember are mysqli-functions, where the error-message-surpressing @ comes from the times of the old mysql-functions. I don't know if such a contruct is nescessary with the mysqli-functions. I know it was necessary with the old MySQl-function-library.

I think, we cannot avoid searching for every single occurence and check the necessity of surpressing an error message instead of handling the hypothetical error.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Login with email address?

by Micha ⌂, Friday, March 05, 2021, 16:36 (1119 days ago) @ Auge

Hello Auge,

On the other hand a forum operator could uncover socket puppets. ;-)

I believe, this collision only exists in rare cases. I add the UNIQUE property to the user_email field. Moreover, the user_name field was also not a UNIQUE field. I removed the INDEX and add UNIQUE, too, #567.

I think, we cannot avoid searching for every single occurence and check the necessity of surpressing an error message instead of handling the hypothetical error.

It is not a problem to look for @mysqli. But, if the statement is e.g.:

$result = @mysqli_query($connid, "SELECT ....)

how should the modification looks like?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Login with email address?

by Auge ⌂, Friday, March 05, 2021, 16:57 (1119 days ago) @ Micha

Hello

I think, we cannot avoid searching for every single occurence and check the necessity of surpressing an error message instead of handling the hypothetical error.


It is not a problem to look for @mysqli. But, if the statement is e.g.:

$result = @mysqli_query($connid, "SELECT ....)

how should the modification looks like?

I don't know it (without testing). I know, that if myslq_query (old lib) failed, it caused PHP errors in very special cases. That was the reason, Alex muted these errors with @. My problem nowadays is, that I don't know, in which cases the @ was necessary. Thatswhy I don't know, how to test possible differences in the behaviour of the mysqli-lib.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

PHP 8 und @

by Taurec, Thursday, March 11, 2021, 09:06 (1113 days ago) @ Micha

Hallo!

Thank you. I'm currently not sure, how we should handle the @-syntax. Any suggestions?

Gerade dieser @-Operator wurde in der neuen PHP-Version 8 abgeschafft, sollte Fehlermeldungen in künfigen Instanzen der Forumssoftware auf PHP-8-Servern also nicht mehr deaktivieren, vgl.:

"The @ operator will no longer silence fatal errors (E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR, E_RECOVERABLE_ERROR, E_PARSE). Error handlers that expect error_reporting to be 0 when @ is used, should be adjusted to use a mask check instead"

Gruß
Taurec

Avatar

PHP 8 und @

by Auge ⌂, Thursday, March 11, 2021, 14:19 (1113 days ago) @ Taurec

Hallo

Thank you. I'm currently not sure, how we should handle the @-syntax. Any suggestions?


Gerade dieser @-Operator wurde in der neuen PHP-Version 8 abgeschafft, sollte Fehlermeldungen in künfigen Instanzen der Forumssoftware auf PHP-8-Servern also nicht mehr deaktivieren

Warum werden wir wohl darüber sprechen? Wir sind uns dessen schon bewusst, wissen aber noch nicht, wie wir damit umgehen sollen und wo ein vergleichbares Verhalten überhaupt noch gebraucht wird.

vgl.:

"The @ operator will no longer silence fatal errors (E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR, E_RECOVERABLE_ERROR, E_PARSE). Error handlers that expect error_reporting to be 0 when @ is used, should be adjusted to use a mask check instead"

Wobei der Text meiner Meinung nach nicht unbedingt selbsterklärend ist.

"The @ operator will no longer silence fatal errors (E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR, E_RECOVERABLE_ERROR, E_PARSE)."

Hervorhebung von mir. Kann man die Meldung nicht fataler Fehler, die nicht in die Gruppe der aufgelisteten Fehlertypen fallen, weiterhin mit @ unterdrücken oder funktioniert das grundsätzlich nicht mehr?

Auch der Text wegen des Sharps (#) als Kommentarzeichens ist für mich bei nochmaliger Lektüre nicht so klar, wie ich ihn vor knapp zwei Wochen interpretiert habe.

"#[ is no longer interpreted as the start of a comment, as this syntax is now used for attributes."

Wenn ich da genau hinschaue (das ist mMn schlechte Typografie in der PHP-Doku), sieht es so aus, dass # durchaus noch als Kommentarzeichen taugt und nur die Kombination von # mit unmittelbar folgendem [, also #[, nicht mehr funktionieren wird.

Wenn das so ist, hätte sich Micha die Mühe nicht machen müssen, das alles umzubauen. Wobei die Ersetzung von # durch // nichts kaputt macht, außer in HTML-Fragmenten mit CSS, die in PHP-Dateien eingebettet sind (ich glaube etwas derartiges gesehen zu haben).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

PHP 8 Kommentarzeichen

by Micha ⌂, Thursday, March 11, 2021, 16:52 (1113 days ago) @ Auge

Hallo,

"#[ is no longer interpreted as the start of a comment, as this syntax is now used for attributes."


Wenn ich da genau hinschaue (das ist mMn schlechte Typografie in der PHP-Doku), sieht es so aus, dass # durchaus noch als Kommentarzeichen taugt und nur die Kombination von # mit unmittelbar folgendem [, also #[, nicht mehr funktionieren wird.

Wenn das so ist, hätte sich Micha die Mühe nicht machen müssen, das alles umzubauen.

Das ist (leider) so. Ich habe inzwischen mal PHP8 ausprobiert. Umsonst? Naja, nicht so tragisch. Letztlich ist es ein Suchen und Ersetzen, was halbwegs fix ging. Der Umbau mit dem @ wird sicher größer. Das @ selbst stört auch erst einmal nicht - es hat nur keine Funktion mehr. Im Moment ist Smarty das größte Problem und wirft extrem viele Warnings in PHP8.

Bei den MySQL Funktionen würde ich auch anfangen umzubauen. Aber zum einen weiß ich noch nicht genau wie und zum anderen haben wir derzeit einige Zweige offen, und ich fände es irgendwie schöner, wenn wir die mal abarbeiten, bevor wir an die SQL-Sachen gehen. Sonst sieht man nachher gar nicht mehr durch...

Bei den SQL-Sachen hatte ich überlegt, ob wir die Gunst der Stunde vielleicht nutzen, und auf denn OOP Ansatz umstellen, sowie Prepared Statement verwenden. Hier fände ich es super, wenn wir einfach eine Strategie haben, die wir immer Anwenden (also wie ein Template).

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

PHP 8 Kommentarzeichen

by Auge ⌂, Thursday, March 11, 2021, 21:22 (1113 days ago) @ Micha

Hallo

"#[ is no longer interpreted as the start of a comment, as this syntax is now used for attributes."


Wenn ich da genau hinschaue, sieht es so aus, dass # durchaus noch als Kommentarzeichen taugt …

Wenn das so ist, hätte sich Micha die Mühe nicht machen müssen, das alles umzubauen.


Das ist (leider) so. Ich habe inzwischen mal PHP8 ausprobiert. Umsonst? Naja, nicht so tragisch. Letztlich ist es ein Suchen und Ersetzen, was halbwegs fix ging.

O.k., umsonst ist der falsche Begriff. Unnötigerweise trifft es wohl besser.

Der Umbau mit dem @ wird sicher größer. Das @ selbst stört auch erst einmal nicht - es hat nur keine Funktion mehr. Im Moment ist Smarty das größte Problem und wirft extrem viele Warnings in PHP8.

Solange wir Smarty benutzen und es noch keine zu PHP8 kompatible Smarty-Version gibt, gibt es halt auch keine zu PHP8 kompatible MLF-Version. Das ist schlicht so.

Bei den MySQL Funktionen würde ich auch anfangen umzubauen. Aber zum einen weiß ich noch nicht genau wie und zum anderen haben wir derzeit einige Zweige offen, und ich fände es irgendwie schöner, wenn wir die mal abarbeiten, bevor wir an die SQL-Sachen gehen. Sonst sieht man nachher gar nicht mehr durch...

Du hast zweifelsohne recht.

Bei den SQL-Sachen hatte ich überlegt, ob wir die Gunst der Stunde vielleicht nutzen, und auf denn OOP Ansatz umstellen …

Meinst du OOP mit MySQLi oder PDO? Ich weiß nicht, welche Vorteile es bringt, innerhalb von MySQLi von prozeduralem auf OOP-Stil umzustellen. Kannst du dazu etwas ausführen?

… sowie Prepared Statement verwenden.

Oh ja, das hätte was. Ich benutze die an einem MS-SQL-Server mit Python und PHP. Leider hat die PHP-Lib für MS-SQL nicht alle Möglichkeiten, die MySQL bietet. So kann man keine benannten Parameter an ein Statement übergeben. Heißt, dass man im Array mit den Parametern gewissenhaft auf deren Reihenfolge achten muss. Alles in allem sind Prepared Statements aber etwas feines.

Hier fände ich es super, wenn wir einfach eine Strategie haben, die wir immer Anwenden (also wie ein Template).

Ja.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

PHP 8 Kommentarzeichen

by Micha ⌂, Friday, March 12, 2021, 07:26 (1113 days ago) @ Auge

Hallo,

Bei den SQL-Sachen hatte ich überlegt, ob wir die Gunst der Stunde vielleicht nutzen, und auf denn OOP Ansatz umstellen …


Meinst du OOP mit MySQLi oder PDO? Ich weiß nicht, welche Vorteile es bringt, innerhalb von MySQLi von prozeduralem auf OOP-Stil umzustellen. Kannst du dazu etwas ausführen?

Die Vor- und Nachteile zwischen beiden Ansätzen sind, denke ich, soweit bekannt und können direkt auf unseren konkreten Fall übertragen werden. Das allein würde mich aber nicht zum Umstellen motivieren. Ich fürchte vielmehr, dass man die Doppelentwicklung seitens PHP irgendwann einstellt und wir in PHP1x auf einmal mit dieser Situation konfrontiert werden. Das ist sicher weit weg (sofern es tatsächlich so kommt) aber wenn wir nun schon alle Ausdrücke anfassen, könnte man dies direkt mit erledigen. Nur um Missverständnisse vorzubeugen: Ich kann sehr gut mit der bisherigen Variante leben und sehe daher kein Grund, Überzeugungsarbeit leisten zu müssen. Daher auch die Wortwahl: Gunst der Stunde. ;-)

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

PHP 8 Kommentarzeichen

by Auge ⌂, Friday, March 12, 2021, 12:01 (1112 days ago) @ Micha

Hallo

Nur um Missverständnisse vorzubeugen: Ich kann sehr gut mit der bisherigen Variante leben und sehe daher kein Grund, Überzeugungsarbeit leisten zu müssen. Daher auch die Wortwahl: Gunst der Stunde. ;-)

Ich wollte mich keineswegs von dir überzeugen lassen. Mich trieb nur die Frage um, ob ein Umstieg von prozeduralem MySQLi auf MySQLi in OOP-Schreibweise sinnvoll wäre, falls es denn das sein sollte, was du im Sinn hast.

Ich weiß nicht, welche Vorteile es bringt, innerhalb von MySQLi von prozeduralem auf OOP-Stil umzustellen. Kannst du dazu etwas ausführen?

Wenn du einen Umstieg auf PDO im Sinne haben solltest, stellt sich diese Frage natürlich nicht.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

PHP 8 Kommentarzeichen

by Micha ⌂, Friday, March 12, 2021, 12:14 (1112 days ago) @ Auge

Hallo Heiko,

Wenn du einen Umstieg auf PDO im Sinne haben solltest, stellt sich diese Frage natürlich nicht.

Ja, vermutlich. Um aber jeden Zweifel zu beseitigen. Ich rede hiervon

$mysqli = new mysqli("127.0.0.1", "user", "password", "database", 3306);
echo $mysqli->host_info . "\n";

Dies ist für mich der OOP Ansatz (der von PHP wohl als PDO bezeichnet wird). Ich wollte also keine eigenen Klassen entwickeln, falls das so rüberkam. Entschuldigung wg. des Missverständnisses.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

PHP 8 Kommentarzeichen

by Auge ⌂, Friday, March 12, 2021, 13:17 (1112 days ago) @ Micha

Hallo

Wenn du einen Umstieg auf PDO im Sinne haben solltest, stellt sich diese Frage natürlich nicht.


Ja, vermutlich. Um aber jeden Zweifel zu beseitigen. Ich rede hiervon

$mysqli = new mysqli("127.0.0.1", "user", "password", "database", 3306);
echo $mysqli->host_info . "\n";

Dies ist für mich der OOP Ansatz (der von PHP wohl als PDO bezeichnet wird).

Nee, PDO ist ein von MySQLi unabhängiges System. Deshalb ritt ich ja so auf prozeduraler und objektorientierter Schreibweise von MySQLi in Abgrenzung zu PDO herum.

Verbindungsaufnahme per PDO:

/* Connect to a MySQL database using driver invocation */
$dsn = 'mysql:dbname=mlf2_database;host=localhost';
$user = 'dbuser';
$password = 'dbpassw0rd';
 
$dbHandle = new PDO($dsn, $user, $password);

Was du da zeigst, ist die objektorientierte Schreibweise von MySQLi.

Beispiele aus der PHP-Doku zu mysqli_connect a.k.a. mysqli::connect a.k.a. mysqli::__construct.

MySQLi objektorientierte Schreibweise:

/* You should enable error reporting for mysqli before attempting to make a connection */
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
 
$dbHandle = new mysqli('localhost', 'my_user', 'my_password', 'my_db');
 
/* Set the desired charset after establishing a connection */
$dbHandle->set_charset('utf8mb4');
 
printf("Success... %s\n", $dbHandle->host_info);

MySQLi prozedurale Schreibweise:

/* You should enable error reporting for mysqli before attempting to make a connection */
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
 
$dbHandle = mysqli_connect('localhost', 'my_user', 'my_password', 'my_db');
 
/* Set the desired charset after establishing a connection */
mysqli_set_charset($dbHandle, 'utf8mb4');
 
printf("Success... %s\n", mysqli_get_host_info($dbHandle));

Das sind also zwei beziehungsweise zweieinhalb verschiedene Systeme.

Ich wollte also keine eigenen Klassen entwickeln, falls das so rüberkam.

Nee, das Rad neu zu erfinden und mutmaßlich schlechter zu machen, als es das Original ist, wollte ich keineswegs vorschlagen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

PHP 8 Kommentarzeichen

by Micha ⌂, Friday, March 12, 2021, 13:47 (1112 days ago) @ Auge

Hallo Heiko,

Nee, PDO ist ein von MySQLi unabhängiges System. Deshalb ritt ich ja so auf prozeduraler und objektorientierter Schreibweise von MySQLi in Abgrenzung zu PDO herum.

Okay, auch damit könnte ich mich arrangieren, wenn das die bevorzugte Variante ist.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

MySQL-Libs in PHP

by Auge ⌂, Friday, March 12, 2021, 14:30 (1112 days ago) @ Micha

Hallo

Nee, PDO ist ein von MySQLi unabhängiges System. Deshalb ritt ich ja so auf prozeduraler und objektorientierter Schreibweise von MySQLi in Abgrenzung zu PDO herum.


Okay, auch damit könnte ich mich arrangieren, wenn das die bevorzugte Variante ist.

Keine Ahnung, ob wir PDO bevorzugen sollten. Ich habe halt keinerlei Erfahrung damit. Ich habe auch keinerlei Erfahung mit der objektorientierten Notation in MySQLi. Das war auch der Grund, dich zu fragen, wo du die Vorteile der objektorientierten Schreibweise von MySQLi gegenüber der prozeduralen Schreibweise von MySQLi siehst.

Offensichtlich geht es dir aber eher darum, auf eine Schreibweise umzustellen, die wir für zukunftssicher halten können. Das ist natürlich eine andere, gleichfalls nachvollziehbare Motivation.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

MySQL-Libs in PHP

by Micha ⌂, Friday, March 12, 2021, 14:49 (1112 days ago) @ Auge

Hallo Auge,

Offensichtlich geht es dir aber eher darum, auf eine Schreibweise umzustellen, die wir für zukunftssicher halten können. Das ist natürlich eine andere, gleichfalls nachvollziehbare Motivation.

Ja, dass ist praktisch die einzige Motivation. Da ich ebenfalls die OOP bzw. PDO Variante ansonsten nicht beurteilen kann, bin ich hier offen. PDO scheint den Vorteil zu haben, dass man auch schnell mal eine andere DB nutzen könnte als MySQL. Ob man das aber jemals nutzt, ist fraglich. Lass uns die Entscheidung noch offenhalten, bis wir die noch offenen Zweige abgearbeitet haben. Dieses Problem läuft uns nicht weg...

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

MySQL-Libs in PHP

by Emil, Wednesday, June 02, 2021, 19:47 (1030 days ago) @ Micha

PDO scheint den Vorteil zu haben, dass man auch schnell mal eine andere DB nutzen könnte als MySQL. Ob man das aber jemals nutzt, ist fraglich.

Wer ist "man"? :)

Ich habe heute MLF entdeckt und gleich installiert. Ich würde z.B. sqlite3 bevorzugen, weil es für meinen Anwendungsbereich völlig ausreichend.

Ich hatte aber auch schon Situationen wo ich Mysql und Postgres jeweils für eine Webandwendung nebeneinander laufen hatte. Da ist es schon sehr praktisch, wenn man die Wahl hat und sich nur um einen Datenbankserver kümmern muss.

Avatar

MySQL-Libs in PHP

by Auge ⌂, Thursday, June 03, 2021, 08:26 (1029 days ago) @ Emil

Hallo

PDO scheint den Vorteil zu haben, dass man auch schnell mal eine andere DB nutzen könnte als MySQL. Ob man das aber jemals nutzt, ist fraglich.


Wer ist "man"? :)

Ich habe heute MLF entdeckt und gleich installiert. Ich würde z.B. sqlite3 bevorzugen, weil es für meinen Anwendungsbereich völlig ausreichend.

Das hieße aber, dass alle Queries in allen verfügbar sein sollenden Dialekten vorgehalten werden müssten. Es ist ja keineswegs so, dass das SQL in MySQL, PostGreSQL, MS SQL, SQLite und was sonst noch alles infrage käme für alle Aufgaben die selbe Syntax verwenden würde.

Allein die Paginierung von Postings, also das aufteilen einer Menge von Datensätzen auf mehrere Ausgabeseiten, bringt in manchen SQL-Dialekten die Notwendigkeit absurder Klimmzüge mit sich. Ist das in MySQL und PostGreSQL mit der Limit-Klausel noch identisch gelöst (LIMIT $start, $anzahl), benötigt man beispielsweise in MS SQL die Schreibweise OFFSET @start ROWS FETCH NEXT @anzahl ROWS ONLY. Das funktioniert aber erst seit MS SQL Server 12, bei früheren Versionen brauchte man für soetwas ein nicht gut lesbares Konstrukt von Sub-Queries (siehe die erste Antwort dieses Threads (von Aaron Bertrand), ab "prior to that, ...".

Da stellt sich ganz schnell die Frage, welches System in welcher Version unterstützt werden soll und was eben nicht.

Ich hatte aber auch schon Situationen wo ich Mysql und Postgres jeweils für eine Webandwendung nebeneinander laufen hatte. Da ist es schon sehr praktisch, wenn man die Wahl hat und sich nur um einen Datenbankserver kümmern muss.

Das ist unbestritten. Gerade bei selbst gehosteten Systemen, wo man nicht von vornherein auf ein Datenbanksystem und eine Instanz festgelegt ist, kommt man schnell in die Bredouille, dass die Installationspakete der Wunschsoftware den eigenen Datenbankserver als Abhängigkeit definiert, womit man dann gerne auch mit mehreren Instanzen eines Systems (zum Beispiel MySQL) "beglückt" wird. In die Konsolidierung eines solchen Zustands kann man dann gerne mal ein paar -zig Arbeitsstunden versenken.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MySQL-Libs in PHP

by Emil, Thursday, June 03, 2021, 17:20 (1029 days ago) @ Auge
edited by Emil, Thursday, June 03, 2021, 17:44

Verstehe. Ich bin (wieso auch immer) davon ausgegangen, dass PDO soweit abstrahiert, dass man problemlos verschiedene Datenbanken verwenden kann. Wieder was gelernt:

PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.
https://www.php.net/manual/en/intro.pdo.php

Verschiedene SQL Queries für jede unterstützte Datenbank zu pflegen macht bei einem kleinen Projekt vermutlich eher mehr Arbeit (und Bugs), als es Vorteile bringt. Klar wäre es schön wenn für die Datenbankabfragen ein Framework benutzt würde. Da gibt es ja einige, wie z.B. Medoo oder Nette Database. Aber wünschen kann man sich viel ... ;)

Avatar

MySQL-Libs in PHP

by Auge ⌂, Friday, June 04, 2021, 12:46 (1028 days ago) @ Emil

Hallo

Verschiedene SQL Queries für jede unterstützte Datenbank zu pflegen macht bei einem kleinen Projekt vermutlich eher mehr Arbeit (und Bugs), als es Vorteile bringt.

Ohne Framework müsste man sich in der verschiedenen Dialekten erstens genug auskennen und zweitens mit einem Templatesystem mit Platzhaltern arbeiten, dass die diversen Abfragen nach SQL-Dialekt sortiert aufbewahrt. Das wäre zwar möglich, bedeutete aber einen erheblichen Umstellungsaufwand. Es gibt genug andere Baustellen, auf denen es so gut wie nicht vorangeht. Wir werden uns nicht noch diese neue Baustelle zusätzlich ans Bein binden.

Klar wäre es schön wenn für die Datenbankabfragen ein Framework benutzt würde. Da gibt es ja einige, wie z.B. Medoo oder Nette Database. Aber wünschen kann man sich viel ... ;)

Nice, die kämen mit ihren Lizenzen (Medoo: MIT, Nette: BSD, GPL 2 oder GPL 3) sogar grundsätzlich infrage. Aktuell aktiv sind die Projekte ebenfalls. Ob die alles können, was wir brauchen und ob die Mindestanforderungen (PHP 7.3 aufwärts, diese oder jene PHP-Bibliothek) bei unserem Publikum erfüllt wären, sei mal dahingestellt. Aber auch hier gälte es den erheblichen Umbauaufwand zu berücksichtigen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread