[Neos] FYI: Summary of todays "Technical Meeting"
Bastian Waidelich
bastian at typo3.org
Tue Apr 15 16:05:53 CEST 2014
Hi all,
we just had another nice little technical meeting. Here a brief summary
of what has been discussed. You can also see (a better readable) version
on http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings:
Participants: Karsten Dambekalns, Dominique Feyer, Sebastian Kurfürst,
Robert Lemke, Christian Müller, Bastian Waidelich
= Todos/Updates from the previous meetings =
* Jira: has been installed and we currently use/evaluate it for the Neos
sprint planning
* ExtDirect replacement: has been merged and released with Neos 1.1 beta ✌
* Support for relative/aliased namespaces in Flow: has been fixed in all
affected branches: https://review.typo3.org/28490
* Dynamic configuration of selector elements: No updates, see
http://forum.typo3.org/index.php/t/203184/
* Improved handling for TargetNotFound exceptions: I didn't come around
that one yet, will do asap - check https://review.typo3.org/27535 for
updates
= Summary of the last meeting (15th April 2014) =
* "Rules" workflow concept: We skipped that one because Søren wasn't there
== Optimize database step in setup ==
* Initiator(s): Aske Ertmann
=== Background: ===
Currently the database step runs all migrations instead of just create
or update taking a long time. Creating lots of old tables, renaming,
deleting etc.
Is this necessary or could we improve this and just mark the migrations
executed? At least it would improve the user experience using the setup
since we don't have any warning that it might take long to finish.
=== CONCLUSIONS: ===
For releases we could add some kind of "keyframe" (or base) migration
that contains all required migrations (and skips the ones that are
obsolete) up to that time.
For that we’d need some special handling for those (that marks the
smaller migrations executed).
We’ll still need the smaller migrations for "git users".
Idea: ship "base migration" with distribution that contains a list of
*all* package migrations it covers and add logic that marks those older
package migrations executed when the base migration is processed.
./flow doctrine:migrate
could look at the “distribution migrations” first and then apply all
newer ones afterwards.
== Current state of ACLs ==
* Initiator(s): Bastian Waidelich
=== Background: ===
Andi and Bastian have been working on the ACL implementation and there
are some challenges to solve
=== Possible discussions: ===
* How should "runtime privileges" be persisted?
* Should we introduce "abstract roles"? (e.g. to hide from
neos/administration/users)
* Backwards compatibility: B/C layer vs code migration
=== CONCLUSIONS: ===
Roles and privileges that are added/modified during "runtime" could be
persisted in a global Policy.yaml file or in the database. Both
approaches have some drawbacks though:
* DB:
** We don't want to store configuration in the database because it makes
deployment and staging more complex - for roles and privileges it is a
blurry line though
** If we always load (overlay) configuration from the database we can't
cache it
* Global Policy.yaml
** If we write it to "Configuration/Policy.yaml" (context independent)
this might cause issues with deployment (e.g. surf does not support
files in the global configuration folder)
** Changing the configuration requires the configuration caches to be
flushed (that's probably negligible because it won't happen that often
usually)
We didn't come up with a solution yet, but a good approach might be to
start refactoring the ConfigurationManager so that the current (post)
processing of the different config types (routes, policy, ...) is not
done in the manager but by a configurable processor. Then it would be
easier to hook in to the loading process and override given
configuration options. This wouldn't solve the "persist" challenge though.
Abstract roles: make sense and are implemented with
https://review.typo3.org/28869
Backwards Compatibility: For some PHP classes it might make sense to add
a slim B/C layer in order to make it easier for developers to adjust to
the new API. For configuration (e.g. Policy.yaml format) we should
provide good code migrations that informs the user explicitly *if*
something can't be converted automatically.
== Case insensitive search in TYPO3CR ==
* Initiator(s): Christian Müller
=== Background: ===
Node properties are stored as serialized array in a *binary* column.
This makes it impossible to search for properties *without case
sensitivity*.
=== Possible discussions: ===
Converting the column to TEXT would work for MySQL because it can
convert it to lower case then, but that would have issues with null
bytes at least on PostgreSQL.
Furthermore the "like" operation on the doctrine query object currently
ignores the caseSensitive flag. But that's fixed with
https://review.typo3.org/24368
=== CONCLUSIONS: ===
It's probably not worth/possible to fix this now. But if we could use
JSON instead of a serialized array, the null pointer issue would be
resolved. Furthermore there will be native support for JSON with MySQL
5.7 apparently.
Besides Christian is already working on a solution that makes the
advanced node indexing/searching available without the need for a
dedicated search server like Solr or elasticsearch
--
Bastian Waidelich
More information about the Neos
mailing list