install + update: error in xml prohibts serverrestart

[Ferdinand]

if for some reasons (coding or reference error) loading of xml fails the module remains in state "to be installed/updated" and the server does not restart any more

IMHO a better and more userfriendly solution would be to set all modules to be installed/updated to a safe state "uninstalled" if a xml loading error occurs
or to allow the server to reastart without loading

[xrg (xrg)]

On Friday 08 April 2011, you wrote:
> Public bug reported:
>
> if for some reasons (coding or reference error) loading of xml fails the
> module remains in state "to be installed/updated" and the server does
> not restart any more
>
> IMHO a better and more userfriendly solution would be to set all modules to
> be installed/updated to a safe state "uninstalled" if a xml loading error
> occurs or to allow the server to reastart without loading

That is a long-known issue.

I prefer to leave it as it is, now.
Because, on the other hand, if you load /half/ of your modules (to a running
db, not a new one), you may get different behaviour of your system..

Take the case of stock_no_auto_picking. Would it be reasonable to continue
working with a server that was supposed to load that module and it failed?

I think you also need another remark here:
Instead of reloading the server all the time (on a development environment),
you can use the base_module_import addon[1] to safely test your xml files.

[1] only found on my tree, use with care, please!
--
Say NO to spam and viruses. Stop using Microsoft Windows!

[Ferdinand (office-chricar)]

Hmm
what about rolling back the transaction (the complete install/update)?

[xrg (xrg)]

On Friday 08 April 2011, you wrote:
> Hmm
> what about rolling back the transaction (the complete install/update)?

It does roll back.
But the process of _selecting_ packages for installation belongs to an earlier
transaction. So, you mark the packages, and next time you try to start the
servers, the actual installation transaction may happen. The reason is that
these are different wizard steps, and cannot thus be in a single transaction.
Ah, yes, also, when upgrading packages, the pooler does restart, so we need to
have a persistent state in postgres.

As a corrective step, you should _unselect_ the marked packages after your
"apply selected install/updates" has failed and before any restart of the
server. I appreciate that many admins will forget to do that, and therefore
end up in the situation you describe.

--
Say NO to spam and viruses. Stop using Microsoft Windows!

[Ferdinand (office-chricar)]

Yes that's what I ment with
"MHO a better and more userfriendly solution would be to set all modules to be installed/updated to a safe state "uninstalled" if a xml loading error occurs
or to allow the server to reastart without loading"
in my bug report

I think it's better to do this automatically then request admins to fiddle around in the postgres tables - the only way to get things running currently