[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