[TYPO3-dev] The extbase dilemma

[Jochen Rau]

Hi.

Björn Steinbrink <steinbrink at saltation.de> writes:
>> > [Persistence]
>> You're right that we built our own persistence layer, but the most
>> prominent reason is that we wanted integration into TYPO3 practices;
>> meaning we needed support for stuff like comma-separated lists in
>> relations, and other weird things.
>
> Sounds like a questionable choice to me. I'd dare say that it would have
> made sense to me to primarily support sane data storage models and tell
> people that they'll have to manually do the weird stuff, if they want to
> keep doing that. Or provide some wrappers as some kind of helper for
> backwards compatibility. But "encouraging" things like the
> comma-separated list stuff? I dunno.

Back then, in early 2008, we (mainly Sebastian and I) discussed whether
we should use a 3rd party ORM or a custom made. To implement a
persistence layer based on the FLOW3 code as it was at that point in
time seems to be the best solution to us, because:

- we wanted to avoid duplicated configuration as much as possible 
- we wanted to be able to read the $TCA to gather information about
  tables, fields, and relations
- we had to support the existion tables (fe-users, fe-groups etc.) with
  their comma-separated lists
- the efford of adapting an existing ORM seemed to be more than writing a
  tailored solution.

Furthermore, the persistence layer never meant to be a full-featured ORM
in the first place. It was meant to persist changes made to an aggregate
(object graph). There is, indeed, no public API to build custom joins
other than the dot-operartor ($query->equals("post.tags.name", "foo"))

At that point in time FLOW3 was based on an implementation of the
JSR283. This part got backported to Extbase as the QueryObjectModel. The
Query object on top of it is also mainly a back-port. The layer below is
the Typo3DbBackend and the DataMapper. I only took the skeletton of
these Classes and reimplemented most of the methods in order to work
with v4. So, I take the blame for that.

As people started to use Extbase, we implemented some features that are
really necessary in order to write meaningful queries. Examples are the
contains() or in() methods, and the dot-operator. Those features got
forward-ported to FLOW3.

In early 2010 Karsten encountered a problem with the dirty monitoring
(http://forge.typo3.org/issues/6290). This resulted in some major
changes to the persistence layer of FLOW3. I started to backport these
changes, but realized that this will be a breaking change. So, Sebastian
and I decided to wait for the widget concept and optimize the existing
code base of the persistence layer. Then came Doctrine2.

I hope you don't mind that I elaborated a little bit on the history of
Extbase just to put it into a context.

Certainly, Extbase will look differently today if we started the project
mid 2010.

>> > This check is extremely
>> > expensive and gets even more expensive if there are many extbase-plugins on
>> > a page, because then _all_ objects are checked again for _every_ plugin!
>> Good point, that's a bug which needs to be fixed. The Persistence Layer
>> needs to be reset after each plugin run, or alternatively detect if it
>> is run on the last plugin on the page. Could you open a bug report for
>> this, or even provide a patch? I think that's pretty easy to solve (at
>> least the first solution).
>
> IIRC it's not that easy, or at least wasn't in T3 4.4, due to some
> implementation details. I don't have any details at hand right now
> though.  I'll see if I quickly dig in there tomorrow (err, today
> *sigh*).  But what you face irrespective of how things are implemented,
> is that you don't control the object lifetime. If some "smart" developer
> gets the idea of caching the objects on his own to avoid reloading them,
> simply resetting the persistence layer will get you some hard to debug
> problems. Thus, at the very least, you'd then want to detect
> "invalid"/outdated objects in some way, but right now, I have no idea as
> to how you could do that.

I see some major problems with the software stack we use in Extbase (and
FLOW3) today (besides my sub-optimal implementation of a persistence
layer). PHP lacks a language construction to deal with mutable
states. Every change to an object instance gets immediately visible to
all "readers". There is no mechnism on the language level to get
notified on a state change and to get from one state to an updated state
in a controlled way. Therefore, we have to deal with a lot of "dirty
monitoring". A second problem is the way OOP glues together data and
behaviour. That makes it extremely difficult to add new members and
methods (not beein member of the class hirarchy). As a result, we have
to deal with a lot of complexity (whether we hide it in layers of a
frame-work or not), and that is bad.

I have to pick up my girls at school now. But I will continue participate in this
discussion.

Best
Jochen