Which then leads one to ask the same thing about SQL Server.
If some adapters are removed from the core then there are some things
which need to happen to make sure that non-core adapters do not become
stale:
1.) Each adapter needs a CI environment and it somehow needs to be
synced to changes in the core.
2.) There needs to be an easy way to install adapters.
Personally I'd like to see the entire adapter code be moved into its
own project. Having a common database layer that provides more beyond
DBI is a good thing, IMO, and usable in its own right.
Oracel Adapter :
# Current maintainer: Michael Schoen <schoenm@earthlink.net>
No point in keeping them in core, as that'll just prolong the
devlopment cycle and bug fixing process.
So these stuff can probably go under the same roof that we discussed
for ex-rails plugins.
Speaking only for myself, I'd still need svn and Trac hosting. As long as that can be maintained, core vs. non-core doesn't matter as much. Though I guess I'd still be a bit concerned about an under-informed sense that "standard Rails" wouldn't have Oracle compatibility.
Speaking only for myself, I'd still need svn and Trac hosting. As long
as that can be maintained, core vs. non-core doesn't matter as much.
Though I guess I'd still be a bit concerned about an under-informed
sense that "standard Rails" wouldn't have Oracle compatibility.
Well, as it stands adapters basically can't work properly in plugins.
So before we looked into extracting the commercial adapters, we'd need
to investigate that first :). Hopefully someone implementing a new
adapter will take a look at what's required, then we can start
thinking about what we do with the less-used adapters.
However with an active, hard-working, long-term maintainer, I can't
see any downside to keeping oracle around
