[PHP-DB] PDO + The Role of PHP + SQLite - Am I missing something?
Hi List, It seems that I'm a little confused (and thus frustrated) with PDO in general, and especially when it comes to PECL php_sqlite3. I understand that PDO is a data-access abstraction layer, and as one, is really good. However, the way I see it, is that PDO should just be an added extra, and not the stock-standard for data-access. It should simply wrap a set of low-level libraries that are still exposed to developers should they choose not to use PDO (for whatever reason). While this is true for most databases, how long will it be until the current low-level libraries like PECL php_mysql and PECL php_mysqli are no longer maintained, and we are forced to use PDO? This can be seen with the PECL php_sqlite extension, which is not maintained anymore. I understand why it's not maintained anymore, because there is PECL php_sqlite3. The problem here is that PECL php_sqlite3 only offers an OOP approach, and no procedural approach. So, for developers that want to develop their own data abstraction layers (access or model), they have to now wrap the PECL php_sqlite3 SQLite3 set of classes. This makes the entire layer slower, more complex, and therefore more error-prone. Most developers are forced to use PDO for SQLite 3 access (due to PHP versions or other reasons), which is still a set of classes that bloat any further abstraction they may choose to develop. The following posting shows the unnecessary confusion on this topic: http://lists.macosforge.org/pipermail/macports-users/2009-January/013658.htm l Confusion like this has led to the development of an SQLite 3 procedural extension: http://php-sqlite3.sourceforge.net/pmwiki/pmwiki.php - not to be confused with the current PECL php_sqlite3 (dash vs underscore) But surely if the PECL php_sqlite3 extension has already been developed and included in the default distributions of PHP, it must be possible to include a procedural interface as well? How long will it be before we are forced to use bloated objects for everything we need to do in PHP? Isn't that the great thing about PHP? That at its core it's a great, fast scripting engine with a few core libraries, and then everything else is implemented through extensions? I fully understand the power that OOP offers, and I understand that is a vital part to the maturity of PHP as a *language*, but I just can't see why the speed and elegance of interfacing with low-level extensions using procedural methods should be completely dropped. For me, as a developer, I have enjoyed the freedom (of choice and ability) that PHP offers - the ability to create the next best data-abstraction layer, or MVC framework. Why should these important innovations be made more difficult by forcing the use of bloated libraries - simply because they adhere to strict OOP best practices, and ultimately force developers to create their own extensions, when it takes less time and work to expose the low-level API like the one already wrapped by PECL php_sqlite3. Wouldn't it provide developers with more opportunity if the current PECL php_sqlite3 extension was dropped in favour of PDO, and replaced with a more low-level library like PECL php_sqlite for version 3 databases? That way developers would be able to develop their own access and model abstraction layers with good performance should they choose to, or make use of PDO should they need something a little more robust and feature-full? The Zend Framework's Zend_DB* objects provide both data-access-abstraction and data-model-abstraction, but still have to wrap PDO for data-access. The problem with developing another custom extension is that hosting providers only use stable releases of PHP and PECL, which makes it near impossible to have a custom extension enabled in a shared hosting environment. Not to mention, again, that the notion of developing a custom extension to expose functionality that already exists (like that already wrapped by PECL php-sqlite3), is insane. Am I missing something? Where do I get involved to help improve the situation? All the best, Lawrance. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. - Albert Einstein -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDO + The Role of PHP + SQLite - Am I missing something?
Hi List, It seems that I'm a little confused (and thus frustrated) with PDO in general, and especially when it comes to PECL php_sqlite3. I understand that PDO is a data-access abstraction layer, and as one, is really good. However, the way I see it, is that PDO should just be an added extra, and not the stock-standard for data-access. It should simply wrap a set of low-level libraries that are still exposed to developers should they choose not to use PDO (for whatever reason). While this is true for most databases, how long will it be until the current low-level libraries like PECL php_mysql and PECL php_mysqli are no longer maintained, and we are forced to use PDO? This can be seen with the PECL php_sqlite extension, which is not maintained anymore. I understand why it's not maintained anymore, because there is PECL php_sqlite3. The problem here is that PECL php_sqlite3 only offers an OOP approach, and no procedural approach. So, for developers that want to develop their own data abstraction layers (access or model), they have to now wrap the PECL php_sqlite3 SQLite3 set of classes. This makes the entire layer slower, more complex, and therefore more error-prone. Most developers are forced to use PDO for SQLite 3 access (due to PHP versions or other reasons), which is still a set of classes that bloat any further abstraction they may choose to develop. The following posting shows the unnecessary confusion on this topic: http://lists.macosforge.org/pipermail/macports-users/2009-January/013658.htm l Most of the confusion there is based on misunderstandings, I would say. Confusion like this has led to the development of an SQLite 3 procedural extension: http://php-sqlite3.sourceforge.net/pmwiki/pmwiki.php - not to be confused with the current PECL php_sqlite3 (dash vs underscore) But surely if the PECL php_sqlite3 extension has already been developed and included in the default distributions of PHP, it must be possible to include a procedural interface as well? How long will it be before we are forced to use bloated objects for everything we need to do in PHP? When no procedural developers step up and write the extensions. No point complaining that some developers with an interest in an OOP implementation of an OOP library took the time to do the work. Isn't that the great thing about PHP? That at its core it's a great, fast scripting engine with a few core libraries, and then everything else is implemented through extensions? I fully understand the power that OOP offers, and I understand that is a vital part to the maturity of PHP as a *language*, but I just can't see why the speed and elegance of interfacing with low-level extensions using procedural methods should be completely dropped. For me, as a developer, I have enjoyed the freedom (of choice and ability) that PHP offers - the ability to create the next best data-abstraction layer, or MVC framework. Why should these important innovations be made more difficult by forcing the use of bloated libraries Something of an exaggeration. As the sqlite3 library has an OOP API, it's more likely a procedural interface would be adding the bloat, if any. - simply because they adhere to strict OOP best practices, and ultimately force developers to create their own extensions, when it takes less time and work to expose the low-level API like the one already wrapped by PECL php_sqlite3. Not true, as noted above, SQLite3 uses an OOP API at low-level Wouldn't it provide developers with more opportunity if the current PECL php_sqlite3 extension was dropped in favour of PDO, and replaced with a more low-level library like PECL php_sqlite for version 3 databases? That way developers would be able to develop their own access and model abstraction layers with good performance should they choose to, or make use of PDO should they need something a little more robust and feature-full? The Zend Framework's Zend_DB* objects provide both data-access-abstraction and data-model-abstraction, but still have to wrap PDO for data-access. The PECL extension is NOT the current implementation of the extension. The PDO/PDO_Sqlite extension/driver are separate to the Sqlite3 extension. I'm not familiar with ZF's way of doing things, but I doubt is *has* to use PDO. This is more likely a choice they made. The problem with developing another custom extension is that hosting providers only use stable releases of PHP and PECL, which makes it near impossible to have a custom extension enabled in a shared hosting environment. Not to mention, again, that the notion of developing a custom extension to expose functionality that already exists (like that already wrapped by PECL php-sqlite3), is insane. Agreed. So take your pick of PDO/PDO_sqlite or just SQLite3 extensions. Both are enabled in PHP 5.3.0 by default, and should be in 5.2 builds also. Am I missing something? PDO is not needed to access SQLite3.
[PHP-DB] Extending my login - not sure how to add my code block in
I have a login script that is great and I want to expand on this but not
sure where to place my new code I have written, I have placed it where I
thought but keep getting errors for else and others when attempting to add
this.
The code I am adding is not complete and will change, but I want to learn
where I should be placing this within this code, it will stand me in good
stead learning this as well. I thought by placing it after the if
($num_rows 0) { section and it would perform the else request and execute
my new code, but I get syntax and } kind of errors.
[php]
?php
// Include the connections script to make a database connection.
include(inc/connect.php);
$username = ;
$password = ;
$errorMessage = ;
function quote_smart($value, $handle) {
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
if (!is_numeric($value)) {
$value = ' . mysql_real_escape_string($value, $handle) . ';
}
return $value;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST'){
$username = $_POST['username'];
$password = $_POST['password'];
$username = htmlspecialchars($username);
$password = htmlspecialchars($password);
$db_found = mysql_select_db($db, $connection);
if ($db_found) {
$username = quote_smart($username, $connection);
$password = quote_smart($password, $connection);
$SQL = SELECT * FROM taablea WHERE username = $username AND
password = '.md5($_POST['password']).';
$result = mysql_query($SQL);
$num_rows = mysql_num_rows($result);
if ($result) {
if ($num_rows 0) {
session_start();
$_SESSION['username'] = $_POST[username];
header (Location: index.html);
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
mysql_close($connection);
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
}
?
[/php]
This is my additional code that I am trying to get working so I can write it
better.
[php]
/* New Block*/
else {
session_start();
$_SESSION['attempts'] = +1;
# setup SQL statement
$SQL = INSERT INTO tablebtemp ;
$SQL = $SQL . (sid, username, password, attempts,
ipaddress) VALUES ;
$SQL = $SQL . ('$sid', '$username', '$password',
'$attempts', '$_SERVER[REMOTE_ADDR]') ;
#execute SQL statement
$result = mysql_db_query( *,$SQL,$connection );
# check for error
if (!$result) {
echo(ERROR: . mysql_error() . \n$SQL\n);
}
else {
# setup SQL statement 2
$SQL = SELECT * FROM tablebtemp WHERE sid =
$sid;
$result = mysql_query($SQL);
if (mysql_num_rows($result) ==0) {
$errorMessage = Please check
your username and/or password is correct;
}
else (mysql_num_rows($result) ==3) {
$errorMessage = You are
blocked, please contact us to get unblocked.;
}
/* END */
[/php]
Re: [PHP-DB] Extending my login - not sure how to add my code block in
On Tue, May 11, 2010 at 12:26 PM, Barry Zimmerman
barryzi...@googlemail.com wrote:
I have a login script that is great and I want to expand on this but not
sure where to place my new code I have written, I have placed it where I
thought but keep getting errors for else and others when attempting to add
this.
The code I am adding is not complete and will change, but I want to learn
where I should be placing this within this code, it will stand me in good
stead learning this as well. I thought by placing it after the if
($num_rows 0) { section and it would perform the else request and execute
my new code, but I get syntax and } kind of errors.
[php]
?php
// Include the connections script to make a database connection.
include(inc/connect.php);
$username = ;
$password = ;
$errorMessage = ;
function quote_smart($value, $handle) {
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
if (!is_numeric($value)) {
$value = ' . mysql_real_escape_string($value, $handle) . ';
}
return $value;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST'){
$username = $_POST['username'];
$password = $_POST['password'];
$username = htmlspecialchars($username);
$password = htmlspecialchars($password);
$db_found = mysql_select_db($db, $connection);
if ($db_found) {
$username = quote_smart($username, $connection);
$password = quote_smart($password, $connection);
$SQL = SELECT * FROM taablea WHERE username = $username AND
password = '.md5($_POST['password']).';
$result = mysql_query($SQL);
$num_rows = mysql_num_rows($result);
if ($result) {
if ($num_rows 0) {
session_start();
$_SESSION['username'] = $_POST[username];
header (Location: index.html);
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
mysql_close($connection);
}
else {
$errorMessage = Please check your username and/or password is
correct;
}
}
?
[/php]
This is my additional code that I am trying to get working so I can write it
better.
[php]
/* New Block*/
else {
session_start();
$_SESSION['attempts'] = +1;
# setup SQL statement
$SQL = INSERT INTO tablebtemp ;
$SQL = $SQL . (sid, username, password, attempts,
ipaddress) VALUES ;
$SQL = $SQL . ('$sid', '$username', '$password',
'$attempts', '$_SERVER[REMOTE_ADDR]') ;
#execute SQL statement
$result = mysql_db_query( *,$SQL,$connection );
# check for error
if (!$result) {
echo(ERROR: . mysql_error() . \n$SQL\n);
}
else {
# setup SQL statement 2
$SQL = SELECT * FROM tablebtemp WHERE sid =
$sid;
$result = mysql_query($SQL);
if (mysql_num_rows($result) ==0) {
$errorMessage = Please check
your username and/or password is correct;
}
else (mysql_num_rows($result) ==3) {
$errorMessage = You are
blocked, please contact us to get unblocked.;
}
/* END */
[/php]
create it as a function and call that function where you need to. It
seems to be recording failures/logon attempts, so a call at else on
the checks of the initial logon would make sense.
--
Bastien
Cat, the other other white meat
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
