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@lists.scsys.co.uk
