Hey again,

for the rollback - i think oxid should contain an inbuilt backup function anyways. And this might be triggered before doing anything.
This would be a nice and simple Github project ;) By the way - is admin 2.0 still being developed?
--

mit freundlichen Grüßen
Alexander Kludt


__________________________
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: [email protected]
Website: www.aggrosoft.de

__________________________
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___________________________
Diese Nachricht ist nur für den Empfänger () bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email ([email protected]) Bescheid
über den fälschlichen Erhalt.





Joscha Krug | marmalade.de
21. September 2012 15:06

Let's have a look on other systems:

TYPO3 for example is doing it the way that Danny described.
And the problem with the rollback is exactly the same if you do it manually.

I see no other ways than telling the user,
that they should backup the system before changing it.

Regards Joscha

Am 21.09.2012 14:51, schrieb Kristian Hempel - D³ Data Development:

_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general


Kristian Hempel - D³ Data Development
21. September 2012 14:51

Hi there,
 
the problem lays within updates.
How do you document the changes between versions?
What do you do with legacy data?
What to do if the update fails? (rollback)
 
 
Best regards
D³ Kristian
 
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

Reply via email to