2009-07-23 17 views
5

Ich habe Hunderttausende von Objekten basierend auf Plone-Archetypen (plone 2.5.X), deren Archetypen-Schema auf den neuesten Stand gebracht werden muss. Das Archetype-Schemamigrationstool eignet sich hervorragend für kleine/mittlere Objekte, bringt aber meinen Server in die Knie und versucht, sie alle zu migrieren, bis zu dem Punkt, an dem ich das Skript immer wieder killigniere. Ich würde gerne in der Lage sein, das Schema eines Objekts zu einem Zeitpunkt zu aktualisieren, möglicherweise als das Objekt, wie es abgerufen wurde - ist das möglich? Wenn nicht, andere Ansätze zur Aktualisierung von Archetyp-Schemas in großen Plone-Sites?Wie kann ich das Schema eines einzelnen Archetype-Objekts bei Bedarf in Plone aktualisieren?

Vielen Dank im Voraus!

+0

Entschuldigung, falsch gelesen Ihre Frage, zu schnell von der Marke. archetypes.schemaextender wird dir hier nicht helfen. Ich habe gewählt, um meine Antwort zu löschen. –

+0

Angesichts der Kommentare zu Lennarts, ist es eine Option, einen ZEO-Client hinzuzufügen und die Migration dort durchzuführen? Dies hat möglicherweise weniger Auswirkungen auf die Benutzerfreundlichkeit der Website als das Hosting * und * die Migration für die gleiche Instanz. (Angenommen, das machst du gerade.) –

+0

ja, momentan bin ich aber leider nur zu viel daten. Es verursacht nur Mega-Swap auf dem Zeo-Host, so dass, wenn eine echte Anfrage hereinkommt, es eine lange Zeit braucht, um das Objekt zu bekommen, das es benötigt. Es ist sporadisch natürlich. 2 kurze Anfragen und 5 super lange. es ist ein bummer es scheint nicht ein einfaches faul Upgrade. Wenn ich mehr über den Prozess verstehe, würde ich mich freuen, einen zu schreiben, aber es ist ein wenig geheimnisumwittert. Es ist überraschend, weil es nicht zu den flexiblen Daten passt, die ich erwartet habe. Danke !!! – eleddy

Antwort

0

Obwohl Sie nicht erklären, was "auf die Knie zu bringen" bedeutet, werde ich raten, dass Ihnen der Speicher ausgeht. Wenn dies der Fall ist, ist es wahrscheinlich eine Frage, dass das Skript keine Änderungen an der Festplatte vornimmt. Das Hinzufügen einer transaction.commit() in der Schleife (vorzugsweise mit einem Test, der nur jedes 100. oder 1000. Mal ausführt) sollte das beheben.

Edit: So lag ich falsch, es war kein Speicherproblem. Es scheint, dass der Archetyp Updater das Richtige tut.

+0

Leider ist es nicht nur ein Speicherproblem.Das Update verursacht auch die Last (als Disk IO) zu spike signifikant, und noch wichtiger, Endbenutzer sehen die Auswirkungen des Updates als slooooowness, so dass ich immer manuell eingreifen und es zu töten. Es gibt immer die Möglichkeit eines geplanten Ausfalls, aber ich versuche, das für ein albernes Schema-Update zu vermeiden. Ich habe gerade den Standard-Archetyp-Tool-Update-Code ausgeführt und kann anscheinend nicht finden, wie man ein einzelnes Element aktualisiert, sonst würde ich gerne Schleifen und Commits schreiben. Kannst du ein Beispiel schreiben, wie du diese Schleife schreiben würdest? Danke! – eleddy

+0

Nun, natürlich IO wird spike. Glauben Sie, dass Sie die Datenbank massiv aktualisieren können, ohne dass sie auf die Festplatte geschrieben wird? Du scheinst kein wirkliches Problem zu haben. Führe das Archetypen-Upgrade durch. –

+0

natürlich ist es ein Problem, wenn zahlende Kunden entweder Mist Antwortzeit für Stunden oder einen vollständigen Ausfall erhalten.Ich denke, es ist sehr fair, ein Element nach dem anderen zu aktualisieren, und ich dachte, das wäre eine einfache Antwort mit einem kleinen Codeschnipsel. wenn es nicht möglich ist, dann ist es nicht möglich und ich werde anfangen, andere Optionen zu betrachten. Ich bin hier auf der Suche nach Code - kein Vortrag darüber, was mein Problem ist. – eleddy

5

nachdem sie durch den 2.5-Katalog Code zu graben, habe ich endlich die Antwort auf einen faulen Schema Update:

if not self._isSchemaCurrent(): 
    logging.debug("updating schema for %s"%self.absolute_url()) 
     try: 
      import transaction 
      transaction.begin() 
      self._updateSchema() 
      transaction.commit() 
     except Exception, e: 
      logging.error('Error updating schema at %s: %s'%(self.absolute_url(), e)) 
      return False 
else: 
    logging.debug("schema for %s is up to date"%self.absolute_url()) 
    return True 

Beachten Sie, dass diese Plone 2.5.3 und von dem, was ich durch plone 3 Looks Graben etwas anders. Für einige Objekte, für die ich bereits ProcessForm angepasst habe, führe ich das Upgrade dort durch, damit das Formular das neue Feld anzeigen kann und es wird verarbeitet. Für andere nur im at_post_edit_script-Hook, da diese meist keine mega wichtigen Schema-Upgrades haben. Darüber hinaus ist die Formularverarbeitung ohnehin der langsamste Teil der Website, so dass die Benutzererfahrung nicht so stark beeinträchtigt wird.

Seine Hacky aber es verursacht keine I/O-Splurges und es funktioniert mit allen Versionen von Objekten. Ich nehme es!

+0

Wie/wo binden Sie diesen Code ein? – rjmunro

+0

@rjmunro Ich habe einen benutzerdefinierten Archetyp-Code und lege diesen an verschiedenen Stellen an, je nachdem, wie schnell ich das Upgrade benötige. Die meisten Orte sind es die at_post_edit Haken. In einem Fall möchte ich, dass das Upgrade vor der Bearbeitung stattfindet, also habe ich processForm überschrieben, damit es vor der Bearbeitung aktualisiert wird. Auf diese Weise kann ich den neuen Schema-Inhalt manuell zum Bearbeitungsformular hinzufügen und muss dann nicht befürchten, dass er es nicht nimmt. Ich habe auch etwas Ähnliches für die Aktualisierung des Arbeitsablaufs gemacht. In diesem Fall habe ich einen Aufruf an ein Skript oben in der Ansichtsvorlage getätigt, das das Update in der Ansicht auslöst. lassen Sie mich wissen, wenn Sie Code Beispiele wollen :) – eleddy