[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dtp-dev] Firebird enablement in DTP
|
Roman,
> Do you mean that general contract is to return null if schema is not
supported? ...
My main concern was to avoid the NPE. DTP committers working on this part
of the code would be able to answer what the contract is supposed to be, so
I was concentrating making sure we are doing the necessary checks.
> 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?
Our API freeze is 3/30, but committers can always petition the community to
make changes after that. Based on the current plans, we don't expect a
large number of API changes. One option you might want to consider is that
our 1.5 stream is being built in Eclipse 3.2.2 and tested in 3.3: details
here --
http://wiki.eclipse.org/index.php/DTP_1.5_Build_Environment
Our milestone builds (currently M5) are expected to be stable enough for
development, so you could switch to the 1.5 stream milestones and thereby
minimize later transition risks.
Regards,
John Graham
Eclipse Data Tools Platform PMC Chair
Staff Software Engineer, Sybase, Inc.
http://dataplat.blogspot.com/
Roman Rokytskyy
<rrokytskyy@yahoo
.co.uk> To
Sent by: DTP development mailing list
dtp-dev-bounces@e <dtp-dev@xxxxxxxxxxx>
clipse.org cc
Subject
02/26/2007 11:31 Re: [dtp-dev] Firebird enablement
AM in DTP
Please respond to
DTP development
mailing list
<dtp-dev@eclipse.
org>
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
_______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev
