[geeklog-devel] plugin_autoinstall - two more issues

[Randy Kolenko]

> You missed the point that each line of the autoinstall structure is a 
> function call and that those functions return the sql. So for every 
> group created, every feature created, every group to feature mapping, 
> every table created, every group added to another group, etc. a 
> separate SQL statement is returned. The INSTALLER_install_table 
> function returns a DROP TABLE $tablename string. The 
> INSTALLER_install_group function returns a DELETE FROM groups.... 
> string. The mapping lines return the string to clean the 
> group_assignments table.


Oh, I didn't miss that point... I'm just curious as to how returning 1
line of sql for each step will alleviate deleting data a plugin dumps
into another plugin's tables?  Forget groups, features etc.. I'm talking
about relational data that can take numerous (read tens or hundreds) of
lines of sql code to create related data.


> 
> The reason not to call the uninstall function is to simplify the 
> uninstalll code. Usually a failed install fails in the middle. 

Define "middle".  It could fail at the last step, or the first step --
after numerous database queries, file system manouvers etc. have been
done.


> the reversal strings you only undo what actually was done. Uninstall 
> functions might attempt to do things to files on the filesystem or 
> make updates to other tables. When you only undo the minimum there is 
> less risk of collateral damage. And the uninstall function only has 
> to be written to uninstall a proper installation. It doesn't need to 
> worry about partial installs.


So, why have a plugin uninstall then? It too would undo any table
changes etc.  Full or partial install seems to be a moot point as you're
trying to remove whatever junk you've insertted into the database.  If
you created folders, removing those should not pose any risk as you just
created them.  If you try to remove a folder that doesn't exist, well,
it can't be removed anyways.


> 
> Oh, and if you really wanted to just use the uninstall, you should 
> move the uninstall function to the autoinstall.php file and include 
> that during uninstall not the other way around. Again, some 
> functions.inc files make database calls outside of all functions. If 
> the plugin failed to install, this will most like cause errors. 
> Including the functions.inc is therefore potentially dangerous. The 
> autoinstall.php is designed to be called while the plugin does not 
> exist. In addition, normal operation of the site would no longer have 
> to parse the uninstall function with every web hit. During 99.99% of 
> the time that is dead code.
> 


Well, perhaps its just me, but I think that functions.inc should not
contain any DB calls outside of a function.  That just plainly does not
scale.  Config class stuff aside (as that can be removed to become a
config.php file in highly scalable environments), making db calls,
setting up arrays etc on each page view is a waste of resources
especially if you're not even in the plugin in question.  Just my
$0.0000002 worth.  I've lived it and had to fix that kind of "coding".
Fine for 10 people.  Not so fine for 500 concurrent people.

Perhaps the most straightforward approach would be to pull the
autouninstall out to its own uninstall_defaults.php file and include
that from functions.inc and the auto-install routine.  Now THAT is much
safer all around.


-randy