Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DROP TABLE CASCADE [CORE695] #1064

Open
firebird-automations opened this issue Oct 1, 2002 · 10 comments
Open

DROP TABLE CASCADE [CORE695] #1064

firebird-automations opened this issue Oct 1, 2002 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: bsstmiller (bsstmiller)

Is duplicated by CORE835

Votes: 3

SFID: 617200#⁠
Submitted By: bsstmiller

I would like to see a drop table MYTABLE cascade added
to the system. Often during programming, I want to
nuke the development database (or part of it) and I get
stuck trying to get rid of related objects so I can
recreate them (views, integrity constraints, triggers,
procedures, etc). This slows down programming and
design tremendously.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

priority: Major [ 3 ] => Minor [ 4 ]

Component: Engine [ 10000 ]

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 617200 =>

@firebird-automations
Copy link
Collaborator Author

Commented by: bsstmiller (bsstmiller)

Why was this down graded? I really think it should be a priority in FB3. Right now developers are pushing adoption of FB. Anything you can do to make it easier to develop in FB, should be done.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

There are many other things that are more important. As soon as the tracker is cleaned up regarding priorities (almost everything was imported as "major" and it needs manual adjustments), we'll see when this request could be addressed.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is duplicated by CORE835 [ CORE835 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10719 ] => Firebird [ 15077 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Kevin Sallee (klsallee)

For eight (8) years this request is unaddressed. When might we see movement?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

And for those years it has got just one vote -- yours ;-) Sorry, it doesn't make it looking urgent. Thus it has to wait until someone inside the team will get interested, or until someone outside the team would be willing to sponsor it.

@firebird-automations
Copy link
Collaborator Author

Commented by: Kevin Sallee (klsallee)

For what it is worth my 1 vote is more than received by CORE704, or CORE1211, or CORE2323, or CORE2777, or others posted years later and already fixed with zero (0) votes.

The number of votes alone are clearly not always relevant. And besides, popularity is not alway a good method to organize development as sometimes the tail can then wag the dog from a small but vocal minority who happen to vote (i.e on-line votes are bias and need not be a realistic ratio of the entire user population).

What I do understand, and a better singular explanation, are the difficulty of the task, limits of internal developer interest and resources driving development.

However, leaving anything open for 8 years makes a project look unresponsive, unorganized and a bit cavalier. The development team's management should long ago have audited, such as during the setup of priorities mentioned four (4) years ago, and either assigned orphan issues to developers to address, properly placed it into a future road map, or otherwise dropped it into a "not unloved but abandoned" list. Even "won't fix now" is better than leaving something open for eight years: at least people then know where they stand, and don't wait years (as I and probably others have done) in limbo and uncertainty.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Kevin, the issue is marked as priority "Minor" and open, so it's currently correctly managed. A good design/implementation would be probably accepted, so someone may do it (not forgetting to discuss first, to not waste time and/or money).

I'm not saying that all Major issues is treated as priority over Minor ones, but we must balance resources, and this one seems not trivial to do, what it does is somewhat questionable (in my opinion), and the same thing may be done currently by client tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant