This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Remove implementation dependency on db modules | ||
|---|---|---|---|
| Product: | db | Reporter: | Jaroslav Tulach <jtulach> |
| Component: | Code | Assignee: | Libor Fischmeistr <lfischmeistr> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | abadea, pjiricka |
| Priority: | P3 | Keywords: | API |
| Version: | 4.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | TASK | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 52155 | ||
|
Description
Jaroslav Tulach
2005-02-03 13:37:40 UTC
Cannot be solved in 4.1 because db module has no public API. Although it is used only in enterprise cluster the assumption is that some modules in ide cluster will want to use it in future so we do not want to move db modules into enterprise cluster (although that would solve the immediate problem). I will ask for 4.1 waiver as soon as 4.0_WAIVER_REQUEST keyword is created. In promo-F we have to figure out how to solve this. We can publish the de facto db API as it is now if we do not plan to do any major work on it. If we do (and we probably should) we will provide a replacement for the current private API. DevRev agreed this can be downgraded to P2. Partially improved by moving the db/model (dbschema) module to enterprise1 cluster. This does not remove any implementation dependencies, but it eliminated a cross-cluster implementation dependency on dbschema. Waiver for NetBeans 4.1 approved. Andrei is working on new db explorer API, that will solve the db module. The dbschema will be solved by creating a friend API that will be used only within enterprise cluster (see also issue 54471). The friend API for dbschema was integrated into the trunk yesterday. Well, I would say this is still not completely fixed, because there is an implementation dependency of dbschema on db, which can not be eliminated by the use of the new evolving API in db. This dependency also goes across clusters (enterprise2 to ide6). Still, the major part of this was fixed, so reopening with P3 priority. This last subitem depends on the ability to have both public (evolving) and friend API in one module, discussed as a part of issue 54123. If the impl dep is between "really close" modules[1], then it is relatively ok. I mean - it is not excelent, but we know no better right now. No need to keep an open issue for that until we found what problems it causes. [1] close modules must be in the same cluster, should be developed by the same guys, always build together, the bridge should the thin and externally unvisible db and dbschema don't match Yarda's definition of "really close" (they are not in the same cluster). The impl dep is mainly caused by the usage of libddl part of the db module in order to retrieve the database structure. Another way to remove it (apart from the one Petr mentions) could be to make use of the new database model (as soon as it's ready) instead of libddl. TM 5.0 -> TBD Not doable for 5.5 I think. Not for 6.0 either. We are working on a new metadata model, but currently it's read-only. Perhaps it can be used to replace libddl in the next release, let's give it a shot. Reassigned to new owner. Reassigned to new owner. |