What would be more useful for install/etc

As much as everyone loves speculating about potential
directory 
structures and file formats, theres other stuff to do.

-Error avoidance. Module install and updates will happily go
ahead and 
try to do things which are access denied and then think they
are done. 
We need to check for access before doing these. One for each

combinataion of alter/create and mysql/postgres to get
started.

-Error handling. Output to AJAX (as used in update.php,
among other 
places) should never return HTML errors to the client; or
the JS could 
be more forgiving. Either we need to work with PHP's error
handling 
(I've just about given up on this due to PHP's lack of
sanity) or make 
JS able to handle the PHP error spew.

-- 
Neil Drumm
http://delocalizedham.com/

On 22 Feb 2006, at 7:49 PM, Neil Drumm wrote:
> -Error avoidance. Module install and updates will
happily go ahead  
> and try to do things which are access denied and then
think they  
> are done. We need to check for access before doing
these. One for  
> each combinataion of alter/create and mysql/postgres to
get started.

This is not a 4.7 thing, but I do believe we need to extend
the db  
api to include db_create_table, db_add_index and
db_add_column  
(including the db_drop_* of all these).
Doing this will get rid of those insipid if
($GLOBALS['db_type'])  
conditionals, and provide a good place for checking these  
permissions, including possible temporary database
credential escalation and very very very hopefully merge our
two  
database files (very very hopefully), meaning less code to
maintain  
(yay), and better support for postgres (yay)
and possibly a simpler path to supporting more database
types.


--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com

> As much as everyone loves speculating about potential
directory 
> structures and file formats, theres other stuff to do.

The intent of the thread, as solidified in the subject line,
was a 
discussion about 4.8 or 5.0's approach to the install
system. That 
doesn't invalidate the two things you mention, and neither
does yours 
invalidate mine. They are not, however, in any way, related:
yours is 
talking about improving the capabilities of existing
features in the 
install code, and my thread was how best to abuse the
install system and 
methodology for future versions, which will probably open up
for commits 
in a month or so. The two threads are entirely unrelated.

It's equivalent to me saying "we really shouldn't
think, or heck, even 
talk, about comments as nodes because we still have three
bugs over here 
that need fixing!" While I appreciate your probably
unstated goal to 
focus all efforts toward 4.7, I heartily admit to ignoring
it entirely 
so that I can focus on an area *I* care about, as opposed to
one I know 
nothing about, nor desire to.

-- 
Morbus Iff ( you are nothing without your robot car,
NOTHING! )
Culture: http://www.disobey.com/
and http://www.gamegrene.com/
O'Reilly Author, Weblog, Cook: http://www.oreil
lynet.com/pub/au/779
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff /
jabber.org: morbus

Op woensdag 22 februari 2006 18:49, schreef Neil Drumm:
> -Error avoidance. Module install and updates will
happily go ahead and
> try to do things which are access denied and then think
they are done.
> We need to check for access before doing these. One for
each
> combinataion of alter/create and mysql/postgres to get
started.

- Duplication avoidance: we have no way to avoid folks from
rerunning the 
upgrade if the previous one failed, other thens some words
to "not run the 
upgrade twice"


- split of JoeSchmoe stuff and real stuff (sorry . Upgrading
joeschmoe.com 
is easy. It was done rather well, even in PHPnuke.
Upgrading Bryght or web-log.nl[1] is a biatch, if not plain
impossble w/o a 
lot of custom code.

I beleive, that unless we provide the proper API stuff (like
upgrade) to the 
People That Matter, Drupal will continue being "a nice
alternative" but 
nothing more. 

Bčr -back trying to find ways to upgrade all his multisite
sites- Kessels

[1] http://willy.boerland.com/myblog/ilse_media_didnt
_choose_drupal
-- 
 [ Bčr Kessels | Drupal services www.webschuur.com ]

Bčr Kessels wrote:
> Op woensdag 22 februari 2006 18:49, schreef Neil Drumm:
> 
>>-Error avoidance. Module install and updates will
happily go ahead and
>>try to do things which are access denied and then
think they are done.
>>We need to check for access before doing these. One
for each
>>combinataion of alter/create and mysql/postgres to
get started.
> 
> 
> - Duplication avoidance: we have no way to avoid folks
from rerunning the 
> upgrade if the previous one failed, other thens some
words to "not run the 
> upgrade twice"

After each update the schema version in the system table is
updated as 
well. So if the update selection page is regenerated after a
half-update 
it will be okay. Maybe not perfect, since the browser may
cache the 
previous form values if you use the back button, but
certainly improved 
in 4.7.

> - split of JoeSchmoe stuff and real stuff (sorry . Upgrading
joeschmoe.com 
> is easy. It was done rather well, even in PHPnuke.
> Upgrading Bryght or web-log.nl[1] is a biatch, if not
plain impossble w/o a 
> lot of custom code.

It didn't happen in 4.6 so we can go without it for 4.7.
Its not really 
a huge issue until you get into shared tables, where the
same table 
would be updated twice by two sites.

-- 
Neil Drumm
http://delocalizedham.com/

> > - split of JoeSchmoe stuff and real stuff (sorry
.
Upgrading joeschmoe.com
> > is easy. It was done rather well, even in PHPnuke.
> > Upgrading Bryght or web-log.nl[1] is a biatch, if
not plain impossble w/o a
> > lot of custom code.
>
> It didn't happen in 4.6 so we can go without it for
4.7. Its not really
> a huge issue until you get into shared tables, where
the same table
> would be updated twice by two sites.

The main reason I do not use this nifty feature, and also
recommend
against it for others: No way to have a clean upgrade for a
table shared
across Drupal sites.

On Wed, Feb 22, 2006 at 08:01:19PM -0500, Khalid B wrote:
> On Wed, Feb 22, 2006 at 10:40:37AM -0800, Neil Drumm
wrote:
> > It didn't happen in 4.6 so we can go without it
for 4.7. Its not really
> > a huge issue until you get into shared tables,
where the same table
> > would be updated twice by two sites.
> 
> The main reason I do not use this nifty feature, and
also recommend
> against it for others: No way to have a clean upgrade
for a table shared
> across Drupal sites.

So are y'all saying that the upgrade process doesn't work
for multisite 
Drupal installs that share tables?

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M
P A N Y
            data intensive web and database programming
                http://www.Analy
sisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f:
718-854-0409

> On Wed, Feb 22, 2006 at 08:01:19PM -0500, Khalid B
wrote:
> > On Wed, Feb 22, 2006 at 10:40:37AM -0800, Neil
Drumm wrote:
> > > It didn't happen in 4.6 so we can go without
it for 4.7. Its not really
> > > a huge issue until you get into shared
tables, where the same table
> > > would be updated twice by two sites.
> >
> > The main reason I do not use this nifty feature,
and also recommend
> > against it for others: No way to have a clean
upgrade for a table shared
> > across Drupal sites.
>
> So are y'all saying that the upgrade process doesn't
work for multisite
> Drupal installs that share tables?

I did not try it, but I can't think of how it would work.
The first site would
update the tables, then what is the second site supposed to
do? Ideally
it should skip the update of already updated, but ...

Many people are running it that way. Don't know if anyone
tried upgrading
so they can give feedback on that.

On Wed, Feb 22, 2006 at 09:07:14PM -0500, Khalid B wrote:
> >
> > So are y'all saying that the upgrade process
doesn't work for multisite
> > Drupal installs that share tables?
> 
> I did not try it, but I can't think of how it would
work. The first site would
> update the tables, then what is the second site
supposed to do? Ideally
> it should skip the update of already updated, but ...

Ouch.  Let's see if I can do something about that...

My thought is to run the upgrade once.  Have the process
obtain all of the 
prefix names by parsing all the sites/settings.php files up
front.  I do 
something along these lines in the Database Table Creation
Script:

    http
://drupal.org/files/issues/create.php.v2.txt
    http://drupal.org/node/2
0530

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M
P A N Y
            data intensive web and database programming
                http://www.Analy
sisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f:
718-854-0409

 See http://drupal.org/node/5
0840

This is just a start - many more to go.