• 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

KingCrunch

New member
Im Proposal gab es eine kleine Diskussion darüber dass möglichst alle PHP-Datentypen unterstütz werden.
Sooo viele sind das ja nun auch nicht :D Und wenn du bei Objekten die Bedingung "Serializable" einführst?

-> Wie kann also zwischen einem gecacheden FALSE und einem Fehler-FALSE unterschieden werden.
Nicht besonders hübsch, aber denkbar:
PHP:
return new Zend_Acl_NotFound();
Oder direkt per Container
PHP:
return new Zend_Acl_Value ($value);
 

mabe

New member
Hi Leutz,

Dann können nur noch Serializable-Objekte gespeichert werden, aber leider implementieren nur die wenigsten Klassen das Interface. Zudem liegt das Problem nicht beim speichern. (Da bekomme ich sauber mit, ob was schief gelaufen ist) sonder beim auslesen.

das klingt ja ganz hübsch den Wert jeweils als Objekt zurückzugeben, aber das Problem liegt eine Stufe höher.

Schau dir mal das kleine Beispiel hier an:
PHP:
// store a boolean false
cache_store('id', false);

// get the stored value
$ret = cache_get('id'); // return false on error
if ($ret === false) { // Woher weiß ich, ob das jetzt das gespeicherte false oder ein Feher-false ist ?
    throw Exception('...');
}
 

KingCrunch

New member
Und wenn du Boolean vorher auch serialisierst? Glaub irgendwie sowas wie {b:1} oder so kam da dann raus. Das is allerdings eindeutig von true unterscheidbar.
 

mabe

New member
Und wenn du Boolean vorher auch serialisierst? Glaub irgendwie sowas wie {b:1} oder so kam da dann raus. Das is allerdings eindeutig von true unterscheidbar.
*G* Du meinst false
Das wollte ich eigentlich bei den Backends vermeiden, die mit unterschiedlichen Datentypen umgehen können. Ansonsten kann ich auch weiterhin Arrays reinschreiben.

Wie häufig kommt es eigentlich in der Praxis vor, dass man einen Boolean cacht? ;)
Genau darauf zielt ja die Umfrage ab. Ich müsste Dann nämlich verbieten ein FALSE zu speichern und um das übersichtlicher zu halten sollten dann alle Booleans und evtl. NULL verboten werden ;)

- Die load-Methode würde dann auch ein false zurückliefern anstelle von NULL
- Die test-Methode lefert auch nur noch ein simples true anstelle von last modified
 

KingCrunch

New member
*G* Du meinst false
Neija, b:1 ist true :rolleyes:
Das wollte ich eigentlich bei den Backends vermeiden, die mit unterschiedlichen Datentypen umgehen können. Ansonsten kann ich auch weiterhin Arrays reinschreiben.
Die Frage bleibt, was die Alternativen sein sollen :D
Genau darauf zielt ja die Umfrage ab. Ich müsste Dann nämlich verbieten ein FALSE zu speichern und um das übersichtlicher zu halten sollten dann alle Booleans und evtl. NULL verboten werden
/sign.
- Die load-Methode würde dann auch ein false zurückliefern anstelle von NULL
Fänd ich inkonsequent: load()-Erfolg wäre der Inhalt, aber load()-Misserfolg boolean? Da is null im Sinne von "nichts" irgendwie .. einleuchtender :D
- Die test-Methode lefert auch nur noch ein simples true anstelle von last modified
Öh ... Damit fragt man ja auch nach test() ab, nicht nach lastModified() :confused:
 

mabe

New member
Genau darauf zielt ja die Umfrage ab. Ich müsste Dann nämlich verbieten ein FALSE zu speichern und um das übersichtlicher zu halten sollten dann alle Booleans und evtl. NULL verboten werden
- Die load-Methode würde dann auch ein false zurückliefern anstelle von NULL
Fänd ich inkonsequent: load()-Erfolg wäre der Inhalt, aber load()-Misserfolg boolean? Da is null im Sinne von "nichts" irgendwie .. einleuchtender :D
Das kommt ganz darauf an, ob der Wert NULL erlaubt wird oder nicht. Wenn nicht stimme ich dir zu, wenn doch würde das ein Problem geben.

- Die test-Methode lefert auch nur noch ein simples true anstelle von last modified
Öh ... Damit fragt man ja auch nach test() ab, nicht nach lastModified() :confused:
Stimmt, aber bis jetzt hab ich das vom alten System übernommen und da ist's halt die mtime. Das blöde ist nur, dass nicht alle Backends eine Abfrage nach last modified unterstützen weshalb diese Info komplett unter den Tisch fällt :(
 

KingCrunch

New member
Das kommt ganz darauf an, ob der Wert NULL erlaubt wird oder nicht. Wenn nicht stimme ich dir zu, wenn doch würde das ein Problem geben.
Mal abgesehen davon, dass die Wege der Herrn manchmal unergründlich sind :rolleyes: Wieviel Sinn macht es denn "nichts" zu cachen?!
Aber mal ein Gedankenspiel: load() beim Miss null liefert und man null als Wert erlaubt, wäre es dann nicht äquivalent dazu, dass du null bei save() zwar entgegen nimmst, aber nicht speicherst? Glaub, ich beantworte mir das selbst: test() würde dann etwas Falsches liefern ...
Stimmt, aber bis jetzt hab ich das vom alten System übernommen und da ist's halt die mtime. Das blöde ist nur, dass nicht alle Backends eine Abfrage nach last modified unterstützen weshalb diese Info komplett unter den Tisch fällt
Kann man die nicht parallel "cachen"? Issn bissl wien Workaround, aber sollte doch eigentlich gehn.
 

mabe

New member
Aber mal ein Gedankenspiel: load() beim Miss null liefert und man null als Wert erlaubt, wäre es dann nicht äquivalent dazu, dass du null bei save() zwar entgegen nimmst, aber nicht speicherst? Glaub, ich beantworte mir das selbst: test() würde dann etwas Falsches liefern ...
so ist es

Kann man die nicht parallel "cachen"? Issn bissl wien Workaround, aber sollte doch eigentlich gehn.
So ist auch das aktuelle Verhalten:
PHP:
// schreiben
return cache_store('id', array($data, time(), $ttl), $ttl)
// lesen (Die Tests jetzt mal weggelassen)
$arr = cache_get('id');
return $arr[0];
Das aber logischerweise mehr Performance und Speicher frisst, als wenn man es ohne den Umweg über das Array macht. Daher stellt sich die Frage, ob man das überhaupt braucht.
-> Performance einbüßen, um last modified ermitteln zu können ?
Meines Wissens wird last modified nur im TwoLevels-Backend und im File-Frontend benötigt, aber es würde auch reichen diese zusätzlich benötigten Infos nur dort zu speichern, wo sie auch benötigt werden.
 
Oben