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
Comments
Modified by: @dyemanovpriority: Major [ 3 ] => Minor [ 4 ] Component: Engine [ 10000 ] assignee: Dmitry Yemanov [ dimitr ] SF_ID: 617200 => |
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. |
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. |
Modified by: @pcisarassignee: Dmitry Yemanov [ dimitr ] => |
Modified by: @pcisarWorkflow: jira [ 10719 ] => Firebird [ 15077 ] |
Commented by: Kevin Sallee (klsallee) For eight (8) years this request is unaddressed. When might we see movement? |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: