[TYPO3-mvc] Oracle DB Backend

[Zachary Davis]

Just wanted to update this thread... We've made nice progress on the 
ExtBase Oracle DB backend, and we now have a fully functional extension 
with a handful of views and repositories. The repositories are using the 
standard extBase query object and our Oracle DB backend. All of the 
select functionality seems to be working well, including limits, 
sorting, joins and queries using the "LIKE" operator.

We haven't yet tackled inserts and updates, but will as soon as the need 
presents itself.

best,
Zach


Zachary Davis wrote:
> I have a client that's using DBAL with an Oracle database backend. My
> understanding is that ExtBase is not currently working with Oracle
> (correct, right?) However, we intend to use ExtBase for this project,
> and we're ready to dig in and do what needs to be done to make ExtBase
> work with Oracle. I'd like to do this in such a way that the work can be
> reused by others and potentially brought into the ExtBase (and/or DBAL).
>
>  From what I've seen on the newsgroups, there is some disagreement about
> how to approach this. If I understand the discussion correctly, one
> approach would be to try to make DBAL support the various query
> mechanisms that ExtBase uses (eg, sub-selects). Another approach would
> be to write a DB backend in ExtBase that is geared at Oracle.
>
> What I want to avoid doing is going in a direction with this that isn't
> the direction that the various folks involved involved with ExtBase and
> DBAL want to take, thereby reducing the likelihood that the work we do
> can be used by others.
>
> My question, then, is whether someone here can point me in the general
> direction that we should take on this project. Is writing a new storage
> backend in ExtBase the path that will most likely lead to our work
> getting committed? Or will we be better off working on DBAL and it's
> query parsing mechanisms? Or is there a another, better approach here
> that I'm not seeing? If someone from the ExtBase team could give me some
> general direction on where would be the best place to implement this,
> I'm pretty confident we can take it from there.
>
> best,
> Zach
>