Re: A discussion of DBIC governance and future development

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: A discussion of DBIC governance and future development

Colin Newell
I and the company I work for are a heavy user of DBIC.  We consider
it's well being and stability to have been amazing so far.

Having largely single developer maintain the project has always amazed
me, and as great as some of the results have been in the past, it
doesn't look like it's really a healthy or sustainable thing to
continue with.

We do want to see DBIC development continue.  It's the best ORM type
thing I've come across in any language by a long way.  But that
doesn't mean it's completely perfect.  Allowing more flexibility with
joins would be really useful.  Moving some of the frew's helpers into
core would also help new users find a lot of the features.

Keeping DBIC stable while adding features is definitely a huge
challenge, and with a less than ideal transfer that's not going to be
any easier.  I think we need to take that risk and continue with it
though.

One thing that I think we might want to consider is something like the
Python PEP process for adding major new functionality.  The trick with
DBIC is not making it do clever things, but it's often making the
interface easy and intuitive to use, while still managing all that
complexity under the hood.

In the case of the DBIC joins for example adding an interface that
allows the type of join to be varied and join parameters to be
specified is tricky.  Not least because you need to consider things
like alias names and what happens when multiple calls to search get
collapsed down into a single query when it all finally executes.  DBIC
already has a bit of that functionality, but it's not terribly easy to
access.  If we could discuss what interface we want to use without
cutting code, and the trade offs it involves then hopefully that gives
us a better chance of delivering major features in a stable fashion.
That would give us a head start on the documentation, and we'd have a
reasonable chance of writing tests early too.  It would also give us
an idea of what major development is in the works.

See [1] for an example of a Python PEP.  I believe there is a chunk of
discussion around the document, and then when everyone agrees it is
finalized.  Then code is written.  That's not to say that exploratory
code can't be written, but it's not a requirement.

I would like to say thank you to Ribasushi for what's he's done with
DBIC so far, and all the help he has provided.  DBIC wouldn't be as
awesome as it is without his hard work.

[1] https://www.python.org/dev/peps/pep-0506/


Colin.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...