[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dtp-dev] Firebird enablement in DTP
- From: Roman Rokytskyy <rrokytskyy@xxxxxxxxxxx>
- Date: Mon, 26 Feb 2007 17:31:29 +0100
- Delivered-to: email@example.com
- User-agent: Thunderbird 2.0b2 (Windows/20070116)
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
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
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?