many of you probably know Jonathan, Guilherme and myself as being the core developers of the Doctrine project over the past 2 years. While this constancy is a good thing it's also problematic. Over the years there were quite some people who were getting interested in becoming active committers and then suddenly disappeared. As a result there are 2 large code bases (1.x, 2.x) with just 3 people. Knowing that, it should be no surprise that Doctrine 2 has mostly been a one man spare-time project for at least a year now. That's just not enough. The project is moving, but it's moving too slowly (and the "truck factor" is insane). I say that because I know what is going on (and also contribute to) ORM projects in other languages.
So we are left wondering. What can we do differently to get more people involved? Given the amount of users and noise about Doctrine around the php scene, I find the absence of new contributors quite strange and I think we're doing something wrong but I don't know what, so I'm asking all of you.
This mail is not meant to be a desperate cry for help but just a heads up about the fact that the Doctrine project needs more active committers and contributors, both for 1.x and for 2.x and I would like to know what we can do better to make it more attractive or easier for people to get involved. Doctrine is a great project and it's really worth getting involved.
I'll be happy to help, and I already tried, but there were a major
obstacle : even when I submitted patches, the tickets were slow to be
answered.
I'll be very glad to improve my consistency with Doctrine's coding
standards, but if you don't say me what is wrong with my patches, it's
gonna be hard ;)
As we use Doctrine for all our PHP-related projects in my (small)
company, I can spend some time to patch / commit on Doctrine, but I
can't see how to do that if you don't spend some time on guiding new
developpers.
My two cents ;)
P.S. : and sorry for my english, i'm a frenchy ;) hope it does not
hurt anyone ?
P.S.2 : my tickets are #2007 and #2038 ;)
On 22 mai, 11:43, Roman Borschel <r.borsc...@gmx.net> wrote:
> many of you probably know Jonathan, Guilherme and myself as being the
> core developers of the Doctrine project over the past 2 years. While
> this constancy is a good thing it's also problematic. Over the years
> there were quite some people who were getting interested in becoming
> active committers and then suddenly disappeared.
> As a result there are 2 large code bases (1.x, 2.x) with just 3
> people. Knowing that, it should be no surprise that Doctrine 2 has
> mostly been a one man spare-time project for at least a year now.
> That's just not enough. The project is moving, but it's moving too
> slowly (and the "truck factor" is insane). I say that because I know
> what is going on (and also contribute to) ORM projects in other
> languages.
> So we are left wondering. What can we do differently to get more
> people involved? Given the amount of users and noise about Doctrine
> around the php scene, I find the absence of new contributors quite
> strange and I think we're doing something wrong but I don't know what,
> so I'm asking all of you.
> This mail is not meant to be a desperate cry for help but just a heads
> up about the fact that the Doctrine project needs more active
> committers and contributors, both for 1.x and for 2.x and I would like
> to know what we can do better to make it more attractive or easier for
> people to get involved. Doctrine is a great project and it's really
> worth getting involved.
sad to read, i always thought that there are working more developers
on doctrine than the three you always read the names of.
Impressive what you guys have done so far.
Well i am currently working on solving two, so called bugs,
and two features i miss so far.
I dont think, that this is the right place to explain everything in
detail,
but i never used "Trac" before and i even dont know how to submit a
ticket,
seems i have to take a closer look at this tool.
Even if your post was not a "desperate cry for help", you could ask
the guys of phpdeveloper.org if they could make an announcement that
doctrine needs help of its users,
or start some kind of a competition for developers, where they were
forced to contribute features they miss on doctrine.
I also think that you guys maybe interact more with the community by
using the blog on the doctrine page,
i got it on my dashboard rss reader, taking a look on it every day,
but fresh postings are a rare thing =)
Tell the community on what you are working at the moment, maybe they
come up with ideas or already written code.
So, just as adrien in its post, i have to apologize for my english.
I am looking forward to help doctrine being a better library.
Greetings,
Sebastian
On 22 Mai, 11:43, Roman Borschel <r.borsc...@gmx.net> wrote:
> many of you probably know Jonathan, Guilherme and myself as being the
> core developers of the Doctrine project over the past 2 years. While
> this constancy is a good thing it's also problematic. Over the years
> there were quite some people who were getting interested in becoming
> active committers and then suddenly disappeared.
> As a result there are 2 large code bases (1.x, 2.x) with just 3
> people. Knowing that, it should be no surprise that Doctrine 2 has
> mostly been a one man spare-time project for at least a year now.
> That's just not enough. The project is moving, but it's moving too
> slowly (and the "truck factor" is insane). I say that because I know
> what is going on (and also contribute to) ORM projects in other
> languages.
> So we are left wondering. What can we do differently to get more
> people involved? Given the amount of users and noise about Doctrine
> around the php scene, I find the absence of new contributors quite
> strange and I think we're doing something wrong but I don't know what,
> so I'm asking all of you.
> This mail is not meant to be a desperate cry for help but just a heads
> up about the fact that the Doctrine project needs more active
> committers and contributors, both for 1.x and for 2.x and I would like
> to know what we can do better to make it more attractive or easier for
> people to get involved. Doctrine is a great project and it's really
> worth getting involved.
On Fri, May 22, 2009 at 9:47 PM, s.golasch <s.gola...@googlemail.com> wrote: > I also think that you guys maybe interact more with the community by > using the blog on the doctrine page,
I agree with Sebastian here. I think you could create quite some buzz if you'd post about the new things in Doctrine 2.0 regularly. The new way of configuring records, for example, is truly amazing. But if you don't dig into the unit tests of the 2.0 code base you never find that out.
Unfortunately I do not have enough time to participate, although I think that I know the Doctrine (1.0) already fairly well due to debugging it regularly ;-) I hope to help you by trying to create patches for the tickets I submit though!
> On Fri, May 22, 2009 at 9:47 PM, s.golasch <s.gola...@googlemail.com>
> wrote:
> > I also think that you guys maybe interact more with the community by
> > using the blog on the doctrine page,
> I agree with Sebastian here. I think you could create quite some buzz
> if you'd post about the new things in Doctrine 2.0 regularly. The new
> way of configuring records, for example, is truly amazing. But if you
> don't dig into the unit tests of the 2.0 code base you never find that
> out.
> Unfortunately I do not have enough time to participate, although I
> think that I know the Doctrine (1.0) already fairly well due to
> debugging it regularly ;-) I hope to help you by trying to create
> patches for the tickets I submit though!
> I'll be happy to help, and I already tried, but there were a major > obstacle : even when I submitted patches, the tickets were slow to be > answered. > I'll be very glad to improve my consistency with Doctrine's coding > standards, but if you don't say me what is wrong with my patches, it's > gonna be hard ;)
> As we use Doctrine for all our PHP-related projects in my (small) > company, I can spend some time to patch / commit on Doctrine, but I > can't see how to do that if you don't spend some time on guiding new > developpers.
> My two cents ;)
> P.S. : and sorry for my english, i'm a frenchy ;) hope it does not > hurt anyone ? > P.S.2 : my tickets are #2007 and #2038 ;)
Thanks for your feedback. Believe me, your help is really appreciated even if it does not really shine through due to delayed reaction on tickets. The main reason I did not even notice these tickets is that I'm pretty much focused on the Doctrine 2 codebase these days while Jonathan and Guilherme maintain and improve the 1.x codebase. I think your tickets will be taken care of soon.
It's unfortunately not always possible to quickly answer tickets, do not let that discourage you! You can even send a notice on this list if you feel your issue gets neglected.
> sad to read, i always thought that there are working more developers > on doctrine than the three you always read the names of. > Impressive what you guys have done so far.
> Well i am currently working on solving two, so called bugs, > and two features i miss so far.
> I dont think, that this is the right place to explain everything in > detail, > but i never used "Trac" before and i even dont know how to submit a > ticket, > seems i have to take a closer look at this tool.
This mailing list can never be wrong. You can of course explain your issues here! (At the end of the day there should be a ticket in Trac of course)
> Even if your post was not a "desperate cry for help", you could ask > the guys of phpdeveloper.org if they could make an announcement that > doctrine needs help of its users, > or start some kind of a competition for developers, where they were > forced to contribute features they miss on doctrine.
Thanks for the suggestion, we might do that!
> I also think that you guys maybe interact more with the community by > using the blog on the doctrine page, > i got it on my dashboard rss reader, taking a look on it every day, > but fresh postings are a rare thing =) > Tell the community on what you are working at the moment, maybe they > come up with ideas or already written code.
Fair point. We will start blogging more from now on.
> So, just as adrien in its post, i have to apologize for my english. > I am looking forward to help doctrine being a better library.
Nice to hear that there will be more information about 2.0.
The only comment, if your goal is to get more contributors involved, it is necessary to talk not only about the planned capabilities in general, but also describe internals and discuss why such decisions were taken.
> We talked about it some. We had talked about it in the past, when > 2.0 neared > we'd begin making more posts. So, what better time to start then > now :)
> Jonathan H. Wage (+1 415 992 5468) > Open Source Software Developer & Evangelist > sensiolabs.com | jwage.com | doctrine-project.org | symfony- > project.org
> On Fri, May 22, 2009 at 4:05 PM, Bernhard Schussek <bschus...@gmail.com > >wrote: >> On Fri, May 22, 2009 at 9:47 PM, s.golasch <s.gola...@googlemail.com> >> wrote: >>> I also think that you guys maybe interact more with the community by >>> using the blog on the doctrine page,
>> I agree with Sebastian here. I think you could create quite some buzz >> if you'd post about the new things in Doctrine 2.0 regularly. The new >> way of configuring records, for example, is truly amazing. But if you >> don't dig into the unit tests of the 2.0 code base you never find >> that >> out.
>> Unfortunately I do not have enough time to participate, although I >> think that I know the Doctrine (1.0) already fairly well due to >> debugging it regularly ;-) I hope to help you by trying to create >> patches for the tickets I submit though!
Last year, before Jonathan announced he was going to work with
symfony, I had already changed our choice to Doctrine. Some people on
my job did not understand why to spend my work with it, because propel
was "native" and more integrated, but I was convinced doctrine was a
better choice.
And today I work in another place and I still use doctrine on every
project I develop. So I worry myself to hear your needs. I thought
either there were more developers involved. Sometimes I have opened
tickets and tried to help either, but since I'm involved on another
open source project (that uses doctrine as orm, by the way) and some
personal projects, I unfortunately do not have time to help now. One
thing I will do is to post your email on some mail lists to let people
know your needs.
A thing I think might help you on this goal to get more people
involved is to focus on "community management". Joomla is a CMS that
I prefer not to use because of some personal reasons and experience,
but is an example of this.
They have:
"developer blogs", annoucing what they are thinking allways. Sometimes
it's almost repetitive, but it informs who is getting there by the
first time.
a dedicated developer page:
http://developer.joomla.org/ and lots of other features.
Of course this kind of thing needs people to get them done. But, I
think you might take at least little steps on this direction. I know
doctrine is an awesome group when it comes to technical quality and
answers. But I think that if you spend more effort on the community
you might get a lot of help.
One practical thing I suggest is to have a developer page on the site,
with easy to access information on:
Where each release and version is heading.
What contribution is needed on these releases and headings.
Technical and architectural decisions communication.
How to contribute.
How to submit a bug.
How to submit a patch.
How to write a test.
Who to contact for doubts.
> Nice to hear that there will be more information about 2.0.
> The only comment, if your goal is to get more contributors involved,
> it is necessary to talk not only about the planned capabilities in
> general, but also describe internals and discuss why such decisions
> were taken.
> On 23.05.2009, at 7:12, Jonathan Wage wrote:
>> We talked about it some. We had talked about it in the past, when
>> 2.0 neared
>> we'd begin making more posts. So, what better time to start then
>> now :)
>> Jonathan H. Wage (+1 415 992 5468)
>> Open Source Software Developer & Evangelist
>> sensiolabs.com | jwage.com | doctrine-project.org | symfony-
>> project.org
>> On Fri, May 22, 2009 at 4:05 PM, Bernhard Schussek <bschus...@gmail.com
>> >wrote:
>>> On Fri, May 22, 2009 at 9:47 PM, s.golasch <s.gola...@googlemail.com>
>>> wrote:
>>>> I also think that you guys maybe interact more with the community by
>>>> using the blog on the doctrine page,
>>> I agree with Sebastian here. I think you could create quite some buzz
>>> if you'd post about the new things in Doctrine 2.0 regularly. The new
>>> way of configuring records, for example, is truly amazing. But if you
>>> don't dig into the unit tests of the 2.0 code base you never find
>>> that
>>> out.
>>> Unfortunately I do not have enough time to participate, although I
>>> think that I know the Doctrine (1.0) already fairly well due to
>>> debugging it regularly ;-) I hope to help you by trying to create
>>> patches for the tickets I submit though!
My personal feeling is that the project is well done, so it seems already complete and rich of developers from the outside. This feeling may be preventing new developers to approach doctrine and come inside. As I said in #docrine-dev: just tell the world outside what is the situation inside: if you need help, help will come (you are doctrine !).
I'll echo this sentiment (which a number of people have suggested). Blog
(or write to the list) about specific design decisions, challenges, etc.
If you open up the process people will have a better understanding of
where and how they can help.
> -----Original Message-----
> From: doctrine-dev@googlegroups.com [mailto:doctrine-
> dev@googlegroups.com] On Behalf Of Davide Riccardo Gabrielli
> Sent: Saturday, May 23, 2009 1:58 PM
> To: doctrine-dev@googlegroups.com
> Subject: [doctrine-dev] Re: Contributors/Committers
> My personal feeling is that the project is well done, so it seems
> already complete and rich of developers from the outside.
> This feeling may be preventing new developers to approach doctrine and
> come inside.
> As I said in #docrine-dev: just tell the world outside what is the
> situation inside: if you need help, help will come (you are doctrine
> !).
Roman has documented a lot of information for 2.0 on the trac wiki. We
agreed that I will try and take his information and post it in a more
accessible way on the blog, twitter, articles, etc. so the information is
more easily available to the public.
adam.hutt...@fracturedatlas.org> wrote:
> I'll echo this sentiment (which a number of people have suggested). Blog
> (or write to the list) about specific design decisions, challenges, etc. If
> you open up the process people will have a better understanding of where and
> how they can help.
> Adam
> > -----Original Message-----
> > From: doctrine-dev@googlegroups.com [mailto:doctrine- <doctrine->
> > dev@googlegroups.com] On Behalf Of Davide Riccardo Gabrielli
> > Sent: Saturday, May 23, 2009 1:58 PM
> > To: doctrine-dev@googlegroups.com
> > Subject: [doctrine-dev] Re: Contributors/Committers
> > My personal feeling is that the project is well done, so it seems
> > already complete and rich of developers from the outside.
> > This feeling may be preventing new developers to approach doctrine and
> > come inside.
> > As I said in #docrine-dev: just tell the world outside what is the
> > situation inside: if you need help, help will come (you are doctrine
> > !).
The slow response to acknowledge and triage the trac tickets is one
thing that does discourage potential contributors. I've filed 6
tickets this month on problems with the Oracle Import code that's run
by the symfony doctrine:build-schema task. After 6 fixes and
workarounds I now have the schema and model built for our 256 table
database. I know many other people would simply give up and stick
with Propel 1.2 or move off to Python.
There is still one Oracle problem that remains unresolved, and that
affects both Doctrine and Propel, it's the non-existent support for
CLOBs in PDO. I've posted to symfony, propel, PDO and DrEvil, with no
responses as to a proper fix. My current workaround involves getting
an OCI8 connection. I get the impression that many on these projects
don't like Oracle, so they don't test it, and don't take it very
seriously.
With the purchase of MySQL by Sun, and Sun by Oracle, I don't expect
MySQL as we know it to last very long. If Larry gets his way we will
all be using Oracle, so lets at least ensure our code supports it.
So far I'm quite impressed with Doctrine even though I'm getting to
know its internals better than I know DQL.
Thanks/peter
On May 23, 2:10 pm, Jonathan Wage <jonw...@gmail.com> wrote:
> Roman has documented a lot of information for 2.0 on the trac wiki. We
> agreed that I will try and take his information and post it in a more
> accessible way on the blog, twitter, articles, etc. so the information is
> more easily available to the public.
> Jonathan H. Wage (+1 415 992 5468)
> Open Source Software Developer & Evangelist
> sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org
> On Sat, May 23, 2009 at 1:01 PM, Adam Huttler <
> adam.hutt...@fracturedatlas.org> wrote:
> > I'll echo this sentiment (which a number of people have suggested). Blog
> > (or write to the list) about specific design decisions, challenges, etc. If
> > you open up the process people will have a better understanding of where and
> > how they can help.
> > > My personal feeling is that the project is well done, so it seems
> > > already complete and rich of developers from the outside.
> > > This feeling may be preventing new developers to approach doctrine and
> > > come inside.
> > > As I said in #docrine-dev: just tell the world outside what is the
> > > situation inside: if you need help, help will come (you are doctrine
> > > !).
Part of the issue is until recently we haven't had anyway to test oracle and
some other dbms. A few of us now have almost all the dbms ready to test
against. I will even have mssql in a virtual machine soon. So we can now
test all the dbms and get it working 100%.
Jonathan H. Wage (+1 415 992 5468)
Open Source Software Developer & Evangelist
sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org
On Mon, May 25, 2009 at 1:34 PM, pkw <pkwoos...@gmail.com> wrote:
> The slow response to acknowledge and triage the trac tickets is one
> thing that does discourage potential contributors. I've filed 6
> tickets this month on problems with the Oracle Import code that's run
> by the symfony doctrine:build-schema task. After 6 fixes and
> workarounds I now have the schema and model built for our 256 table
> database. I know many other people would simply give up and stick
> with Propel 1.2 or move off to Python.
> There is still one Oracle problem that remains unresolved, and that
> affects both Doctrine and Propel, it's the non-existent support for
> CLOBs in PDO. I've posted to symfony, propel, PDO and DrEvil, with no
> responses as to a proper fix. My current workaround involves getting
> an OCI8 connection. I get the impression that many on these projects
> don't like Oracle, so they don't test it, and don't take it very
> seriously.
> With the purchase of MySQL by Sun, and Sun by Oracle, I don't expect
> MySQL as we know it to last very long. If Larry gets his way we will
> all be using Oracle, so lets at least ensure our code supports it.
> So far I'm quite impressed with Doctrine even though I'm getting to
> know its internals better than I know DQL.
> Thanks/peter
> On May 23, 2:10 pm, Jonathan Wage <jonw...@gmail.com> wrote:
> > Roman has documented a lot of information for 2.0 on the trac wiki. We
> > agreed that I will try and take his information and post it in a more
> > accessible way on the blog, twitter, articles, etc. so the information is
> > more easily available to the public.
> > Jonathan H. Wage (+1 415 992 5468)
> > Open Source Software Developer & Evangelist
> > sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org
> > On Sat, May 23, 2009 at 1:01 PM, Adam Huttler <
> > adam.hutt...@fracturedatlas.org> wrote:
> > > I'll echo this sentiment (which a number of people have suggested).
> Blog
> > > (or write to the list) about specific design decisions, challenges,
> etc. If
> > > you open up the process people will have a better understanding of
> where and
> > > how they can help.
> > > > My personal feeling is that the project is well done, so it seems
> > > > already complete and rich of developers from the outside.
> > > > This feeling may be preventing new developers to approach doctrine
> and
> > > > come inside.
> > > > As I said in #docrine-dev: just tell the world outside what is the
> > > > situation inside: if you need help, help will come (you are doctrine
> > > > !).
> The slow response to acknowledge and triage the trac tickets is one > thing that does discourage potential contributors. I've filed 6 > tickets this month on problems with the Oracle Import code that's run > by the symfony doctrine:build-schema task. After 6 fixes and > workarounds I now have the schema and model built for our 256 table > database. I know many other people would simply give up and stick > with Propel 1.2 or move off to Python.
Especially Oracle tickets are problematic because of 2 reasons:
- We don't have a test environment for Oracle (I finally got Oracle to run for me but only through a VM setup under Vista. And the Oracle instant client installation under OS X was still a pain) - The 1.x test suite is not designed to be run effectively against different dbms (this was addressed in the 2.x testsuite)
In addition not that many Doctrine users currently use Oracle (I hope that changes with Doctrine 2). These are all reasons why especially Oracle tickets are often not taken care of properly.
So, yes, Oracle is really a pain with Doctrine 1.x, no doubt about that, its much less enjoyable than working with MySql or PostgreSql.
> There is still one Oracle problem that remains unresolved, and that > affects both Doctrine and Propel, it's the non-existent support for > CLOBs in PDO. I've posted to symfony, propel, PDO and DrEvil, with no > responses as to a proper fix. My current workaround involves getting > an OCI8 connection. I get the impression that many on these projects > don't like Oracle, so they don't test it, and don't take it very > seriously.
Yea and that's sad. That is the reason I did not lock Doctrine 2 to PDO. In fact I already planned to integrate an oci8 driver for Doctrine 2.
> With the purchase of MySQL by Sun, and Sun by Oracle, I don't expect > MySQL as we know it to last very long. If Larry gets his way we will > all be using Oracle, so lets at least ensure our code supports it.
I'm not so concerned about that. According to the official documents published by Oracle after they acquired Sun, MySql is safe. According to them, MySql fits perfectly in their product line ( http://www.oracle.com/sun/sun-faq.pdf ).
Thanks Roman for the detailed response. I really hope that MySql does
survive, I use it in all my smaller projects, but I'm afraid it will
become the Oracle entry level system and will pick up a lot of the
Oracle proprietary "features" that make it so difficult to use, but so
powerful. For example, they have good reasons for the way CLOBs work,
they are able to support very large streamed objects and the
requirement for a transaction makes sense. I wouldn't be surprised to
see the Oracle CLOB added as a datatype in MySql, and the LONGTEXT
eventually desupported.
/peter
On May 25, 3:20 pm, Roman Borschel <r.borsc...@gmx.net> wrote:
> > The slow response to acknowledge and triage the trac tickets is one
> > thing that does discourage potential contributors. I've filed 6
> > tickets this month on problems with the Oracle Import code that's run
> > by the symfony doctrine:build-schema task. After 6 fixes and
> > workarounds I now have the schema and model built for our 256 table
> > database. I know many other people would simply give up and stick
> > with Propel 1.2 or move off to Python.
> Especially Oracle tickets are problematic because of 2 reasons:
> - We don't have a test environment for Oracle (I finally got Oracle to
> run for me but only through a VM setup under Vista. And the Oracle
> instant client installation under OS X was still a pain)
> - The 1.x test suite is not designed to be run effectively against
> different dbms (this was addressed in the 2.x testsuite)
> In addition not that many Doctrine users currently use Oracle (I hope
> that changes with Doctrine 2).
> These are all reasons why especially Oracle tickets are often not
> taken care of properly.
> So, yes, Oracle is really a pain with Doctrine 1.x, no doubt about
> that, its much less enjoyable than working with MySql or PostgreSql.
> > There is still one Oracle problem that remains unresolved, and that
> > affects both Doctrine and Propel, it's the non-existent support for
> > CLOBs in PDO. I've posted to symfony, propel, PDO and DrEvil, with no
> > responses as to a proper fix. My current workaround involves getting
> > an OCI8 connection. I get the impression that many on these projects
> > don't like Oracle, so they don't test it, and don't take it very
> > seriously.
> Yea and that's sad. That is the reason I did not lock Doctrine 2 to
> PDO. In fact I already planned to integrate an oci8 driver for
> Doctrine 2.
> > With the purchase of MySQL by Sun, and Sun by Oracle, I don't expect
> > MySQL as we know it to last very long. If Larry gets his way we will
> > all be using Oracle, so lets at least ensure our code supports it.
> I'm not so concerned about that. According to the official documents
> published by Oracle after they acquired Sun, MySql is safe. According
> to them, MySql fits perfectly in their product line (http://www.oracle.com/sun/sun-faq.pdf > ).
First of all I am really happy, that there are more users using
Doctrine with Oracle.
One note about contributions: If I create a ticket or add a comment to
existing ticket and few days without a response I sometimes completely
forget about it - cause I have a workaround for that or I learn to
live with some issues. When something is modified - new comment, any
question and so on it will be good, if the trac will notify the
interested users like symfony's trac does.
At my work I am using Oracle + Doctrine daily at least one year. I am
working on a project that I run also on MySQL and PostgreSQL without a
problem. I have some custom workarounds and "fixes" for Oracle, that I
don't want to commit, because they can have sideeffects for other devs
(eg. #1592) therefor I need to know the opinion of other
doctrine/oracle users.
Because the only way for proper work with oracle is the Oci8
extension, we need oci8 (supported now through the adapter) to be the
default for oracle - at least for Doctrine 2.0 (sorry, I do not have a
time for closer look at the 2.0 branch at the moment).
It will be also improvement to support adapters in sfDoctrineDatabase
class or maybe to have another sfDoctrineAdapterDatabase class in
sfDoctrinePlugin. Is there someone still using oracle with PDO Oci
instead of the adapter?
Fetching LOB descriptors instead of the content of LOB could be easily
done by moving the fetch flags as an connection attribute that would
be changeable. So If you need this, do not hestitate to send a patch
or when I will have some time, I'll do that, but I never need this
feature with doctrine. Inserting of large objects will be worse.
Also Nested sets and the level column should cause problems, because
LEVEL is oracle's keyword (also used in inheritance context - Connect
By Prior) and the only way to use nested set with oracle is to quote
the identifiers. And quoting identifier is not implemented very well,
and there are still parts where quoting of identifiers didn't work.
And time to time someone posts a ticket about the uppercase of the
oracle identifiers and it will break the code because quoted
identifiers are case sensitive...
Another part that doesn't make sense is dropDb. Usually you have
specified in project one connection - user that have some limited
access to the databases. At least no real user have privileges to
create another user. In Oracle there are no databases like in mysql.
In oracle it is called schema. But schema is represented by a user. So
usually if you want to create schema, you need to craete user without
any privileges or if you create user that can connect and can create
objects, he has access only for the schama named like the user (of
course, grants ... etc... works fine in Oracle). So If you want to
drop database (like in mysql) you need to drop the schema and because
schema is represented by a user, you need to drop and recreate the
user. You have only one user specified in your connection. You have no
rights to create user. You want to drop yourself and create yourself.
It is funny. The best way to simulate dropdb functionality in oracle
is dropping all existing objects in the schema.
> Thanks Roman for the detailed response. I really hope that MySql does
> survive, I use it in all my smaller projects, but I'm afraid it will
> become the Oracle entry level system and will pick up a lot of the
> Oracle proprietary "features" that make it so difficult to use, but so
> powerful. For example, they have good reasons for the way CLOBs work,
> they are able to support very large streamed objects and the
> requirement for a transaction makes sense. I wouldn't be surprised to
> see the Oracle CLOB added as a datatype in MySql, and the LONGTEXT
> eventually desupported.
> /peter
> On May 25, 3:20 pm, Roman Borschel <r.borsc...@gmx.net> wrote:
>> Hi,
>> On May 25, 2009, at 8:34 PM, pkw wrote:
>> > The slow response to acknowledge and triage the trac tickets is one
>> > thing that does discourage potential contributors. I've filed 6
>> > tickets this month on problems with the Oracle Import code that's run
>> > by the symfony doctrine:build-schema task. After 6 fixes and
>> > workarounds I now have the schema and model built for our 256 table
>> > database. I know many other people would simply give up and stick
>> > with Propel 1.2 or move off to Python.
>> Especially Oracle tickets are problematic because of 2 reasons:
>> - We don't have a test environment for Oracle (I finally got Oracle to
>> run for me but only through a VM setup under Vista. And the Oracle
>> instant client installation under OS X was still a pain)
>> - The 1.x test suite is not designed to be run effectively against
>> different dbms (this was addressed in the 2.x testsuite)
>> In addition not that many Doctrine users currently use Oracle (I hope
>> that changes with Doctrine 2).
>> These are all reasons why especially Oracle tickets are often not
>> taken care of properly.
>> So, yes, Oracle is really a pain with Doctrine 1.x, no doubt about
>> that, its much less enjoyable than working with MySql or PostgreSql.
>> > There is still one Oracle problem that remains unresolved, and that
>> > affects both Doctrine and Propel, it's the non-existent support for
>> > CLOBs in PDO. I've posted to symfony, propel, PDO and DrEvil, with no
>> > responses as to a proper fix. My current workaround involves getting
>> > an OCI8 connection. I get the impression that many on these projects
>> > don't like Oracle, so they don't test it, and don't take it very
>> > seriously.
>> Yea and that's sad. That is the reason I did not lock Doctrine 2 to
>> PDO. In fact I already planned to integrate an oci8 driver for
>> Doctrine 2.
>> > With the purchase of MySQL by Sun, and Sun by Oracle, I don't expect
>> > MySQL as we know it to last very long. If Larry gets his way we will
>> > all be using Oracle, so lets at least ensure our code supports it.
>> I'm not so concerned about that. According to the official documents
>> published by Oracle after they acquired Sun, MySql is safe. According
>> to them, MySql fits perfectly in their product line (http://www.oracle.com/sun/sun-faq.pdf >> ).
