Hallo zusammen, anscheinend kommen bei einigen von euch die Frage auf warum wir wieder auf das alte Kategorie Konzept umgestiegen sind. Hier gibt es einfache Gründe für. Der wichtigste Grund war vor allem der zukünftige Einsatz von Doctrine im Frontend. Mit der Gedmo Extension war es so nicht möglich Kategorie Artikel über Doctrine zu selektieren. Zusätzlich hat die doppelte Verknüpfung der s_categories mit den Left und Right Werten im Frontend dazu geführt, dass Queries schlechter skalieren, vor allem in Shops in denen viele Kategorien existieren. "Was der Materialized Path allerdings zusätzlich in der s_categories zu suchen hat, bleibt mir wahrlich schleierhaft. " => Der Path wurde hinzugefügt um nun auch ohne die Gedmo Extension einfach und schnell die Unterkategorien für eine bestimmte Kategorie auszulesen. Zu verlangen dass jeder einen Rekursiven Aufruf für einen kleinen Kategorie Tree implementiert ist natürlich auch nicht zumutbar. „dafür finde ich die s_articles_categories_ro immer noch überflüssig/behindernd, aber das fällt dann wohl unter „Design“/„Altlast“…“ => Die s_articles_categories Tabelle und _ro Tabelle ist bewusst implementiert worden. Diese gehört nicht zur Altlast von Shopware. Mit einer Differenzierung der Tabellen für Schreib und Lese Zugriffe haben wir die Möglichkeit geschaffen die Denormalisierung Asynchron zu triggern. Zudem ist es so auch einfacher für den Drittentwickler eine Artikel - Kategorie Zuordnung zu speichern, da er nun einfach nur die LEAF Kategorie mit der entsprechenden Artikel ID in die s_articles_categories Tabelle schreiben muss und Shopware kümmert sich um die Denormalisierung. Durch diese Schreib Tabelle haben wir zudem die Sicherheit den Kategorie Tree immer wieder korrekt aufzubauen. Ich hoffe damit eure Fragen beantwortet zu haben. Sollten noch Fragen offen sein beantworte ich diese gerne. Mit freundlichen Grüßen Oliver Denter
Also lag es an der ORM Implementierung und nicht am Pattern selbst. Danke für die Aufklärung…!
Ich habe die 4.1 RC kurz im Vergleich zu einer SW 4.0.7 Demoinstallation getestet. Der große Befreiungsschlag ist es leider nicht. Das kann man realistisch betrachtet wahrscheinlich auch nicht erwarten. Aber es ist ein Schritt nach vorne. Die Ladezeiten waren mit leerem Cache durchweg schneller. Bei gecachten Seiten ist der Unterschied nicht so groß - allerdings war es bei uns bisher so, dass merkwürdigerweise erst beim dritten Laden, scheinbar alle Elemente gecached waren. In der 4.1 ist dies bereits beim zweiten Laden der Fall. Eine große Verbesserung bringt der httpCache, der mit der 4.1 endlich final wird und standardmäßig implementiert ist - damit sinken die Ladezeiten bei wiederholtem Aufruf spürbar. Das Backend dagegen ist (weiterhin im Vergleich zur 3.5.6) nachwievor träge und langsam. Die Split-Screen Ansicht für Artikel stellt aber eine große Verbesserung dar und reagiert auch schnell. Ansonsten entsteht vorallem durch geschicktes Nachladen (Artikelansicht) und Visualisieren des Nachladens der Eindruck, dass es schneller geht - tut es aber leider nicht. Man muss aber ganz klar beachten, dass keine speziellen Fälle getestet wurden. Beispielsweise soll es große Verbesserungen bei vielen Varianten geben. In solchen speziellen Konstellationen kann der Unterschied groß sein. Fazit: Wir freuen uns dennoch sehr auf die neue 4.1er - auf sicher etliche Bugfixes und Verbesserungen und vorallem auf den httpCache und die Split-Ansicht.
[quote=„Stefan Hamann“] … Zur 4.2 nochmal kurz - hier ist es geplant vor allem die REST-API funktionell extrem auszubauen - [color=red]zum anderen ein vollständig neues Import/Export Modul, wo ihr „beliebige“ Daten hochladen könnt - da ist also ein Mapper integriert, so dass ihr nicht mehr auf die Standard-Dateiformate von uns angewiesen sein werdet - weiterer Schwerpunkt: Die Unterstützung großer Datenmengen & die Geschwindigkeit der Importe.[/color][/quote] Moin! Kann man schon sagen, ob das nun tatsächlich in der 4.2 kommen wird? LG, AS
Hallo, erst einmal sind folgende Punkte angedacht: http://wiki.shopware.de/_detail_1429.html Mehr kann man aktuell nicht fest/offiziell zusagen zum Release der 4.2.0, welche evtl. weiteren Features kommen und in welchem Umfang. Es geht im ersten Schritt im viele Basis-Elemente und Grundstrukturen, auf die wir dann noch weiter aufbauen können. Das ist also der wichtigste Bestandteil. Es kommen aber in gewohnten Zyklen weitere Updates sowie auch Plugins. Sebastian
Guten Abend Danke für die Rückmeldung. Die Frage zielte eigentlich nicht so sehr auf neue Features. Ob man die Spalten z. B. selbst bestimmen kann ist für uns erst einmal nicht so wichtig. Einen Export als Muster zu nehmen und zu editieren ist ja nun kein Hexenwerk … Es geht mir nur darum, ob der Import / Export von größeren Mengen an Daten (z. B. Atrikeln) in der 4.2 wieder funktionieren wird. In der 3.5 war der Import von zigTausend Artikeln kein Problem. Egal wie lange es dauerte, es lief einfach sauber und zuverlässig durch. In der 4 ist bis dato von dieser Zuverlässigkeit keine Spur mehr … der Punkt wurde ja auch hier im Forum schon ausreichend besprochen. Also für uns ist einfach entscheidend, ob der Import / Export in der 4.2 wieder funktioniert wie man es aus der 3.5 gewohnt war. Wird dem so sein? LG, AS
Hallo, das Ziel ist hier die Performacesteigerung. Ob die selbe große Menge importiert werden kann, kann ich nicht beurteilen. Grundsätzlich ist der Aufwand ja viel viel größer und in keiner Weise vergleichbar mit der alten 3.5 Das fängt ja bei Varianten schon an, die in der 4er viel komplexer und viel mehr Felder und Funktionen haben. Das wird man also evtl. nicht wie in der 3.5er hinbekommen können. Früher waren alle Varianten des Konfigurators in einer einzige Zelle gespeichert. Heute hat ja jede Variante, genau wie ein Artikel, eine eigene Zeile. Das gibt es also gravierende Unterschiede. Das wird sich also alles erst zeigen, wenn nach der Umsetzung die Prüfungen und Performance-Tests anstehen. Vorher ist also alles Vermutung… Das Ziel ist klar und darauf arbeiten hin Sebastian PS: gehört eigentlich nicht hier hin. Hier im Thread gehts um den RC von 4.1 
Guten Morgen Sebastian! Ich dachte es gehört deshalb hier hin, weil Stefan es ja hier geschrieben hatte: allgemein-f25/ab-sofort-4-1-0-rc-verfugbar-schon-jemand-getestet-t13769.html#p63765 Das Argument, dass in der 4 ja alles anders ist weil die Technik dahinter eine ganz andere ist kann ich leider wirklich nicht mehr hören. Es kommt immer dann, wenn etwas nicht (mehr) funktioniert … Tut mir leid wenn ich das mal so sagen muss: das interessiert nicht wirklich. Wenn ich eine Software kaufe und dazu einen Wartungsvertrag abschließe, dann erwarte ich so viel Kontinuität, dass auch in der nächsten Version die Basics aus dem Vorgänger noch funktionieren. Wie der Hersteller das macht ist mir da ziemlich egal. In diesem Falle warten wir vor allem auf ein Import-Export-Modul das wenigstens annähernd das leistet was in der 3.5 schon Standard war. Wir warten darauf nun schon ein Jahr. Der letzte Hoffnungsschimmer war der oben zitierte Beitrag von Stefan. Und nun hast Du irgendwie schon wieder versucht den zu relativieren … hm, schaun wir mal, müssen wir mal sehn, kann man noch nicht sagen, warten wir mal die test ab … schon möglich aber festlegen mag ich mich nicht. Die Ticket-List gibt zu dem Thema gar nix her. Und jedes mal heisst es dann nein, zu dem Thema gibt es kein Ticket, das haben wir ohnehin auf dem Schirm … Kann man denn mal definitiv erfahren, ob das ImExModul in der 4.2 verbessert wird oder eben nicht? Wurde das denn überhaupt angefasst!? Wenn nicht ist auch schon langsam wurscht. Aber kann man es mal wissen dürfen!? Dann kann ich im Zweifel selbst jemanden beauftragen. Aber dieses Gehänge und Gewürge und Gewarte auf die nächste Version um dann festzustellen: war wieder mal nix dabei … kann ich wirklichn langsam nicht mehr haben. Sorry, aber das musste mal raus. :x LG, AS