Announcement

  •  » Engine
  •  » Database improvements

#16 2009-11-15 23:05:51

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13786

Re: Database improvements

grum wrote:

And probably we can use framework dedicated to this..

Before using any framework as database abstraction layer, please check numerous times how much it decreases overall performances. Supporting SQLite/PostgreSQL is nice, making Piwigo slower with MySQL is not.

Offline

 

#17 2009-11-16 00:04:52

P@t
Piwigo Team
Nice
2007-06-13
4098

Re: Database improvements

Local files editor check syntax before saving...
It's also easy to check if $conf['cfgBase'] is defined....
And it's possible to hide database password in editor....


P@t

Offline

 

#18 2009-11-16 00:49:48

grum
Former Piwigo Team
Pantin
2007-09-10
1371

Re: Database improvements

yes it possible, but what is the benefit ?


My pictures with Piwigo, of course !
[ www.grum.fr ]

Offline

 

#19 2009-11-16 07:51:20

VDigital
Former Piwigo Team
Paris (FR)
2005-05-04
17680

Re: Database improvements

Keep only the simplest solution and the most powerful solution.
(Not removable, not editable, but override-able).

Advantages of $conf...
- Global and Unique
- Readiness
- Changeable (Plugin)
- Piwigo backup
- Piwigo upgrade

Being compared to $cfgBase, $cfgUser, $cfgPassword, $cfgHote, $prefixeTable
which are in include/mysql.inc.php, or could be in include/dblayer/mysql.inc.php, include/dblayer/pgsql.inc.php, include/dblayer/sqlite.inc.php,...
- 4 out of 5 began by $cfg (meaning configuration like $conf)
- Unchangeable (I need that a long time ago, I can't remember why maybe for prefix but it was too complex to do).
- backup (include/config_*.inc.php and don't forget mysql.inc.php or include/dblayer/*.inc.php)
- upgrade (pouah) :-(

Keep it simple.


Piwigo.com: Start and run your own photo gallery. Signup and get 30 days to try for free, no commitment.
8-)

Offline

 

#20 2009-11-16 14:31:20

nicolas
Former Piwigo Team
2004-12-30
1232

Re: Database improvements

I think the best solution is to only change mysql.inc.php file name to config_database.inc.php. All config files will have config_ prefix.
The other good thing to change is to rename database configuration varaibles into $conf array. This way, database configuration can be override in config_local.inc.php or by a test framework !

grum wrote:

But I don't understand why we want to allow the database config in the config_local.inc.php ?

You're right. I think it's not a good idea. But I also think it could be a good idea to be able to do that to override default parameters.

grum wrote:

About the database improvment, I can read "I mean using functions like pwg_query() but more specific : pwg_db_connect(), pwg_db_insert(), pwg_db_delete(), pwg_db_mass_insert(),..."
May be we can made a class providing the database functions.
Something like $pwg_db->querie($sql) or $pwg_db->fetch_row()
By using something like this, it will be easiest to use SQLite or PostgreSQL.
And probably we can use framework dedicated to this..

It was my idea but without dedicated framework. Instead of writing something like that :

Code:

$result = pwg_query($query);
while ($row = mysql_fetch_assoc($result)) 
{
//
}

I imagine something like that :

Code:

$result = pwg_query($query);
while ($row = pwg_fetch_assoc($result)) 
{
//
}

The file common.inc.php load only the corresponding functions according to the database layer used. The functions have the same name but are implemented in the right way depending of the database engine.

Offline

 

#21 2009-11-16 14:40:17

VDigital
Former Piwigo Team
Paris (FR)
2005-05-04
17680

Re: Database improvements

I agree your points, Nicolas.
Go head (on my side).


Piwigo.com: Start and run your own photo gallery. Signup and get 30 days to try for free, no commitment.
8-)

Offline

 

#22 2009-11-16 15:18:53

nicolas
Former Piwigo Team
2004-12-30
1232

Re: Database improvements

VDigital wrote:

I agree your points, Nicolas.
Go head (on my side).

grum, p@at et plg do you agree ? Something else to say ?

Offline

 

#23 2009-11-16 15:27:27

rvelices
Former Piwigo Team
2005-12-29
1960

Re: Database improvements

I have skipped this topic.
Nicolas, I agree 100% with you on points 1. and 3.
I have tried already to make these changes through time, but still some parts are not complete. For exemple functions simple_hash_from_query, hash_from_query are already there.
From my point of view, array_from_query should be simple_array_from_query and array_from_query should return the whole data ...

Offline

 

#24 2009-11-16 16:09:17

nicolas
Former Piwigo Team
2004-12-30
1232

Re: Database improvements

rvelices wrote:

I have skipped this topic.

As I want all your advices I forgot to require it by mail.

rvelices wrote:

Nicolas, I agree 100% with you on points 1. and 3.
I have tried already to make these changes through time, but still some parts are not complete. For exemple functions simple_hash_from_query, hash_from_query are already there.
From my point of view, array_from_query should be simple_array_from_query and array_from_query should return the whole data ...

I think in a first step, I will only replace all mysql_* functions by pwg_db* functions.  Of course, I will use all existing such functions.

Offline

 

#25 2009-11-16 21:49:59

grum
Former Piwigo Team
Pantin
2007-09-10
1371

Re: Database improvements

nicolas wrote:

VDigital wrote:

I agree your points, Nicolas.
Go head (on my side).

grum, p@at et plg do you agree ? Something else to say ?

yes !

Just, it will take me some time, because I'm not enough easy with the english to tell quickly and clearly what I want to explain... ^^;


My pictures with Piwigo, of course !
[ www.grum.fr ]

Offline

 

#26 2009-11-16 21:50:23

grum
Former Piwigo Team
Pantin
2007-09-10
1371

Re: Database improvements

yes (i have something else to tell) !
not yes "I totaly agree"


My pictures with Piwigo, of course !
[ www.grum.fr ]

Offline

 

#27 2009-11-16 22:23:29

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13786

Re: Database improvements

rvelices wrote:

For exemple functions simple_hash_from_query, hash_from_query are already there.
From my point of view, array_from_query should be simple_array_from_query and array_from_query should return the whole data ...

With PEM, I really appreciate using functions like array_of_array_from_query (that should be renamed arrays_from_query with the "s"). These are "level 2" functions. Concerning "level 1" function, I'm OK to replace myqsl_num_rows with pwg_num_rows. Have fun nicolas :-)

In PEM, we have a class that declare fetch_row for instance, and you call it with $db->fetch_row instead of mysql_fetch_row. But I admit I much more appreciate the pwg_fetch_row syntax.

Concerning mysql.inc.php moved to config_database.inc.php, I'm OK. I trust your opinions. It's obvious that mysql.inc.php is just a temporary solution that has lasted for too long. Changing variable names to $conf[] : perfect.

Offline

 

#28 2009-11-16 22:31:26

grum
Former Piwigo Team
Pantin
2007-09-10
1371

Re: Database improvements

nicolas wrote:

I imagine something like that :
Code:

$result = pwg_query($query);
while ($row = pwg_fetch_assoc($result))
{
//
}

The file common.inc.php load only the corresponding functions according to the database layer used. The functions have the same name but are implemented in the right way depending of the database engine.

I agree with nicolas
I just wonder if we cannot use POO to do this....

nicolas wrote:

I think the best solution is to only change mysql.inc.php file name to config_database.inc.php. All config files will have config_ prefix.
The other good thing to change is to rename database configuration varaibles into $conf array. This way, database configuration can be override in config_local.inc.php or by a test framework !

grum wrote:

But I don't understand why we want to allow the database config in the config_local.inc.php ?

You're right. I think it's not a good idea. But I also think it could be a good idea to be able to do that to override default parameters.

About using a config_ filename, associated with a $conf var, I totaly agree.
I really don't understand why we need to be able to override the database $conf values.

First, loading the config_default.inc.php file followed immediately by the config_local.inc.php file.
After theses 2 files are loaded, we loads the config_dabase.inc.php file.
If a $conf database value is set in the previous config file, it will be automatically overrided by the value inside the database config file => no risk for the user to make mistake in the config


My pictures with Piwigo, of course !
[ www.grum.fr ]

Offline

 

#29 2009-11-16 22:37:16

plg
Piwigo Team
Nantes, France, Europe
2002-04-05
13786

Re: Database improvements

grum wrote:

I just wonder if we cannot use POO to do this....

This is what PEM does and I admit I don't like the syntax $db->something but I suppose it's only a matter of habit. What is the advantage of $db->fetch_row compared to pwg_fetch_row ? (I suppose you're going to tell me it's cleaner, and it's already a good reason)

grum wrote:

I really don't understand why we need to be able to override the database $conf values.

First, loading the config_default.inc.php file followed immediately by the config_local.inc.php file.
After theses 2 files are loaded, we loads the config_dabase.inc.php file.
If a $conf database value is set in the previous config file, it will be automatically overrided by the value inside the database config file => no risk for the user to make mistake in the config

I agree with you grum. Giving the possibility to override database connection settings with config_local.inc.php makes me feel we're introducing a security issue in some way.

Offline

 

#30 2009-11-16 22:54:03

grum
Former Piwigo Team
Pantin
2007-09-10
1371

Re: Database improvements

plg wrote:

grum wrote:

I just wonder if we cannot use POO to do this....

This is what PEM does and I admit I don't like the syntax $db->something but I suppose it's only a matter of habit. What is the advantage of $db->fetch_row compared to pwg_fetch_row ? (I suppose you're going to tell me it's cleaner, and it's already a good reason)

Look at the templates : Smarty API is encapsuled into an object.
with this, we can easily made new instances of the template system inside function : I found this is very useful

ok, this is not an argument for a db class.
so, another way to use POO is to use the possibility of inheritance, visibility, overload, ....


My pictures with Piwigo, of course !
[ www.grum.fr ]

Offline

 
  •  » Engine
  •  » Database improvements

Board footer

Powered by FluxBB

github twitter newsletter Donate Piwigo.org © 2002-2024 · Contact