Is DrySQL enterprise-ready?
DrySQL is stable, but does not perform well on databases with large numbers of tables at present. Because DrySQL queries your DB's system tables in order to generate the ORM for your application,
some additional DB I/O overhead is incurred. This was originally part of the design to ensure maximum flexibility, and can be useful for DBs with a small to medium number of tables. The current plan is to offer multiple "modes"
of operation for DrySQL: 1 flexibility-centric, and 1 performance-centric.
When will [insert DBMS here] be supported?
Support for additional databases will be added as a result of contributions from the community and/or a significant number of requests from the community.
Anyone considering contributing is invited to check out the source code for DrySQL from the RubyForge SVN repository.
What does the roadmap for DrySQL look like?
There are a few items on the To-Do list at the moment:
- Performance: re-architecting the ORM generation logic in DrySQL to provide a high-performance mode of operation
- Unit tests: increase coverage and check unit tests into DrySQL RubyForge SVN repository
- Support for self-referential constraints (i.e. A Foreign Key defined in Table A that references Table A)
- Support for 1-to-n relationships where n is a constant. (eg. table CHILD has a column MOTHER and a column FATHER, both referencing records in a PARENT table)
- Support for composite primary and foreign keys (composite unique keys are already supported)
- Support for SQLite
If there are features that you would like to see in DrySQL, please contact me.
