• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Zend_Cache Refactoring

mabe

New member
Ich habe das Tagging jetzt mit Hilfe des Tag Handlers eingebaut (nicht getestet - siehe svn).
Dazu gibt es nun die option "tag_handler" und "tag_cache_id_prefix"
 

ice-breaker

New member
Ich habe eben mal nen bisschen über den Code gelesen, schön verständlich !
Aber mir ist auch aufgefallen, dass du die Exceptions nicht ondemand lädst sondern jedesmal (z.B. Zend_Cache_Backend_SqliteAdapter_Abstract oder Zend_Cache_Backend_Abstract), das müsstest du noch ändern, entspricht nicht den Coding Rules.
 

mabe

New member
Ich habe eben mal nen bisschen über den Code gelesen, schön verständlich !
danke danke

Aber mir ist auch aufgefallen, dass du die Exceptions nicht ondemand lädst sondern jedesmal (z.B. Zend_Cache_Backend_SqliteAdapter_Abstract oder Zend_Cache_Backend_Abstract), das müsstest du noch ändern, entspricht nicht den Coding Rules.
Ich wollte das eigentlich erst zum Schluss durchgehen und vor den throws das die Klasse laden.
Eine extra Funktion (z.B: throwException) wollte ich vermeiden, da dann immer die gleiche Zeile als Throw-Punkt angegeben wird.
 

DennisBecker

Super-Moderator
Was mir bei der bisherigen Cache Lösung bei Zend_Cache_Core aufgefallen ist, dass man zwar nen cache_id_prefix angeben kann, dieser aber beim Zend_Cache_Backend_Memcache garnicht benutzt wird (per ngrep die Daten mitgelesen). Es wäre gut, wenn das dann komplett behoben werden würde :)
 

mabe

New member
so da bin ich wieder

jep so sieht's aus - ick bin da marc ;)

@ DennisBecker
das kann ich mir eigentlich gar nicht so richtig vorstellen, da cache_id_prefix von frontend gesetzt wird und die id inkl. des prefixes an das backend geschickt wird.

Allerdings wäre es eine Diskussion wert wo man genau den Prefix/Namespace setzt, da ja ein paar Backends zusätzlich Prefixes/Namespaces unterstützen. Wäre es nicht sinnvoller die Namespace/Prefix - Option von dem Backend erledigen zu lassen und das Frontend nur einspringen lassen, wenn es vom Backend nicht unterstützt wird ?
In folgenden Backends sind Namespaces/Prefixes implementiert:
ZendServer (namespace), File (file_prefix)
 

DennisBecker

Super-Moderator
Hmm... ich Frage mich gerade, warum das nicht jedes Backend können sollte - setzt sich doch eigentlich nur aus 2 Strings zusammen!
 

mabe

New member
Es wäre kein großes Problem das in's alle Backends zu implementieren, man müsste nur aufpassen, dass z.B. das ZendServer-Backend die Info weitergereicht bekommt und nicht vorher zusammengesetzt wird. Im Frontend wäre es dann in der Tat überflüssig.
 

DennisBecker

Super-Moderator
Also wenn dann sollte man das doch einheitlich für alle machen, das hilft dann auch, wenn man ein eigenes Backend schreiben will!
 

robo47

New member
Getrenntes Prefix für Frontend und Backend machen z.b. dann Sinn wenn man eine Instanz eines Backends mit mehreren Frontends nutzen will und abhängig vom Frontend um eventuelle Kollisionen bei verschiedenen Komponenten die das jeweilige Frontend nutzen zu vermeiden, da man dann jedem Frontend ein anderes Prefix nochmal geben kann, aber ob man das oft braucht / nutzt weis ich nicht.
 

DennisBecker

Super-Moderator
Ich sehe das eher von dem Punkt aus, wenn mehrere Domains auf demselben Server laufen, will man eigentlich per Cache-Prefix die Caches von einander trennen.
 

ice-breaker

New member
Die Frage ist ob ZendServer die Info des Prefix und Schlüssels auch sinnvoll nutzt.
Eventuell konkateniert es die beiden Werte einfach, dann könnte man sich die Trennung in Zend_Cache auch sparen.
Sollte es aber diese Information irgendwie für Partitionierung der Schlüssel oder ähnliches nutzen, sollte man dem ZendServer natürlich beide Werte zur Verfügung stellen.
 

ice-breaker

New member
Hmm, ja, dann sollte man es vllt einbauen, wobei das ja scheinbar eher eine Art Tagging ist, da aber beschränkt auf einen Tag.
 

mabe

New member
OK Ich würde die Namespace/Prefix-Funktionalität wie folgt implementieren:
  1. Die Option "namespace" im Frontend als default namespace setzen
  2. Den Namespace als Parameter in $opts in das Backend weitergeben
  3. Das Backend MUSS den Namespace weiter verarbeiten
Dadurch wäre die Funktionalität wie folgt:
PHP:
// Es gibt nur noch eine Option für Namespace/Prefix
$cache = Zend_Cache::factory('Core', 'File', array('namespace' => 'test'));

// Das File-Backend setzt den Namespace vor den Hash-Dateinamen
$cache->load('id1');

// Beim Wechseln des Backends bleibt die "namespace"-Option erhalten
$cache->setBackend(new Zend_Cache_Backend_ZendServer_Disk());

// Das ZendServer-Backend setzt den Namespace vor die id getrennt mit "::"
$cache->load('id1');

// Alle anderen Backends setzen den Namespace vor die id mit einem Trennzeichen
// (Könnte auch das gleiche sein wie bei ZendServer - ist dem Backend überlassen)
$cache->setBackend(new Zend_Cache_Backend_Apc());
$cache->load('id1');

// Es ist zudem möglich den Namespace direkt bei der Abfrage zu definieren
$cache.>load('id1', array('namespace' => 'mynamespace'));
Folgende Optionen fallen dann Weg bzw. werden mit der neuen Option ersetzt:
- Zend_Cache_Frontend_Core "cache_id_prefix"
- Zend_Cache_Backend_File - "file_prefix"
- Zend_Cache_Backend_ZendServer - "namespace"

[EDIT]
Hätte ich fast vergessen, die neue Option "tag_cache_id_prefix" benenne ich dann natürlich um nach "tag_namespace" ;)


Bitte um kurze Rückmeldung
 
Zuletzt bearbeitet:

DennisBecker

Super-Moderator
Das hört sich sehr gut an! So kann man ja immernoch problemlos auf die Eigenheiten / Vorzüge der Backends eingehen. Ich finde den Vorschlag sehr gut :)
 

mabe

New member
kurzer Zwischenstand:

1. Das Backend Memcached ist jetzt implementiert
2. Folgende Methoden akzeptieren mehrere cache ids: test, load, remove, getMetadata
3. Methode getStatus zu getStorageStatus umbenannt und dem Frontend als "public" hinzugefügt
4. Die neue Option "namespace" ist fertig und die anderen (file_prefix & Co.) habe ich entfernt
 

mabe

New member
Im Proposal gab es eine kleine Diskussion darüber dass möglichst alle PHP-Datentypen unterstütz werden. Viele Backends (z.B. apc, memcache, ...) geben ein false zurück, wenn der Datensatz nicht gefunden wurde oder ein Problem entstand.

-> Wie kann also zwischen einem gecacheden FALSE und einem Fehler-FALSE unterschieden werden.

Derzeit wird zu jedem Eintrag ein Array mit den eigentlichen Daten, mtime und ttl gespeichert. Dadurch kann zwar zwischen den beiden FALSE unterschieden werden, aber das macht die ganze Sache langsamer.

Um das zu beschleunigen würde ich das statt einem Array nur noch die eigentlichen Daten speichern, aber dadurch würde folgendes passieren:
1. Die Test-Funktion gibt nur noch ein true oder false zurück
2. FALSE kann man nicht mehr speichern bzw. lesen

Daher habe ich eine Umfrage im Proposal erstellt. Wäre cool, wenn Ihr im Proposal was dazu beitragen könntet ;)
-> http://framework.zend.com/wiki/display/ZFPROP/Zend_Cache+refactoring+-+Marc+Bennewitz

Ich hoffe die Problemstellung war einigermaßen verständlich ;)
 
Oben