> As i understand it, firebird doesn't have a "schema" in this sense either.
Are you sure? http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-ddl-database.html The important things for jOOQ are: - Can objects between different databases/schemata be joined? - Can a schema be prepended (optionally) before a table reference (e.g. SELECT * FROM [my_schema].[my_table]). If yes, then this "database" needs to be considered as a "schema" by jOOQ. Note that currently, jOOQ doesn't really distinguish between database/catalog/schema/user, hence there is some confusion about these things right now. This should be fixed in jOOQ 3.0, hopefully. > Yes, querying the system tables is pretty much the only way (CMIIW) of > getting the internals of Firebird and Interbase. > (Putting stuff here for future reference, just in case:) > > http://www.firebirdfaq.org/faq329/ > http://www.firebirdfaq.org/faq174/ > There's a good writeup (with diagrams and everything!) here: > http://www.firebirdsql.it/download/doc_download/362-the-firebird-system-tables-martijn-tonies- Nice links. The FAQ's indicate that there are some SHOW TABLES, SHOW TABLE commands. That might be easier to use than querying the actual RDB$ tables, if those commands are available through JDBC... > The default JDBC driver for firebird (Jaybird - > http://www.firebirdsql.org/en/jdbc-driver/) has several classes that seems > to do this (e.g. > http://www.jarvana.com/jarvana/view/org/firebirdsql/jdbc/jaybird/2.1.6/jaybird-2.1.6-javadoc.jar!/org/firebirdsql/jdbc/FBDatabaseMetaData.html > ) but i'm not familiar with them nor the API itself; Just in case: jOOQ shouldn't rely on JDBC driver implementations. If it's not available through the standard JDBC API, then it shouldn't be used. > I also couldn't find > much info on whether jaybird fully support the API atm. This is definitely > useful though. I suppose it would be interesting to retrofit a JDBC Metadata > API solution after the basic implementation is done. Whatever seems simpler to you at this time. > Additional question: What's the significance of the "0" attached to the end > of the method names? That's just a silly convention of mine when the public API is in fact implemented using a "final" keyword, delegating some implementation parts to a similar method. Instead of writing public List<SchemaDefinition> getSchemata(); // which calls any of these... protected List<SchemaDefinition> getSchemataImplementation(); protected List<SchemaDefinition> getSchemataTemplate(); protected List<SchemaDefinition> getSchemataDelegate(); ... I just append a zero. In this case, the public final method implements all the stuff related to lazy loading and configurable "includes" / "excludes" filters, such that protected implementations can concentrate on the actual query. Cheers Lukas
