| Re: [dtp-dev] Firebird enablement in DTP |
John,
Yes, these cases should be considered bugs. We'll see if we can scan the DTP code base, identify these cases, and put in the correct checks.
Do you mean that general contract is to return null if schema is not supported? Is it specified somewhere? What about the nodes in DSE then - would DSE view be able to automatically create the tree? I do not know the DTP internals so well, but it looks that it would be almost impossible to enforce such contract.
Frankly, an approach of getting the DatabaseDefinition instance and fetching the database capabilities from it looks to me as much more cleaner.
The only "dirty" part in the code I have posted is obtaining a reference to RDBCorePlugin, especially from within the Modelbase and SQL Tools Data plugins (if I'm not mistaken, they do not import the Connectivity packages directly, so very likely it works only because they happen to reside in the same classloader).
We weren't planning a maintenance release before 1.5, though feedback from the community is very useful in these decisions. In general we try to fix bugs in support of community efforts in the current build stream, and only point release when the next scheduled release is far away, or there is a need for a release build by the community. Assuming that we can work with your bugs/suggestions in the 1.5 stream, would you need a point release before then?
I'm pretty sure that I won't be able to release full-featured support for Firebird before June - I've got the main things sorted out, but now more complex issues are comming (code completion, ddl generation, import/export, etc). I would need to switch later to 1.5 to ensure that released DTP 1.5 can be used by Firebird plugin as well, that is ok.
Would the DTP 1.5 be backward compatible with DTP 1.0 (in other words, how big are the planned API changes)? If yes, when the API would be considered stabilized, so I can plan the switch?
Roman