Summary: | Add support for alter table's design without losing data | ||
---|---|---|---|
Product: | [Applications] KEXI | Reporter: | Bram Schoenmakers <me> |
Component: | Tables | Assignee: | Jarosław Staniek <staniek> |
Status: | ASSIGNED --- | ||
Severity: | wishlist | CC: | carlos.camara, grundleborg, staniek, supcobet, whitfield |
Priority: | NOR | Keywords: | bounty |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
URL: | https://invent.kde.org/office/kexi/-/issues/138 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 301262, 304757 |
Description
Bram Schoenmakers
2006-04-09 22:42:19 UTC
FYI: The feature is in development now for 1.1. What is the status on this? It's partially implemented, what means we cannot dare to enable this by default - many cases are not covered yet. It's already ported to KDE4 so will be a part of Kexi 2.0 or 2.1. Hmm, let's keep it open. I suppose, from what I've seen, that Kexi's problems with ALTER TABLE might've came from sqlite's problems. Maybe it would be a good idea to contribute in sqlite project itself, since code is public domain, so Kexi won't be the-only-one with ALTER support in sqlite-world. @Artur: true, but this would force me to downgrade the toolset used to C from C++ and to self-made facilities (of worse, to glib? aah) from Qt. I've already experienced this problem with mdbtools and I rather have no desire to manage another part created in similar technology. Manageable source (C++ with a good abstraction) is important. The code could be reused at least in KDE and probably - apps that link to Qt libs (not necessary the GUI ones; the code is in KDE4 already), so the audience is not small. To work at sqlite's level, it would need a close collaboration on its 'kernel' level - a task for what I have no motivation, time and even money :) That said, I have been really hoping to see someone working within sqlite on the stuff. Some people think sqlite would be became internally too complex after the adition. *** Bug 234191 has been marked as a duplicate of this bug. *** *** Bug 305506 has been marked as a duplicate of this bug. *** I plan to have simple option: altering some physical properties would require immediate saving of the design but will not remove all the data. Other properties would be enabled for modification even without that. Hopefully for 2.6. Glad to hear that! Willing to have that feature for 2.6 so I will be able to migrate from Libreoffice Base to Kexi after all! Delayed to 2.7 because of limited resources but the result shall be solid. *** Bug 311783 has been marked as a duplicate of this bug. *** Founding possible at https://github.com/staniek/kexi/issues/1 (click Post a bounty on it) *** Bug 379080 has been marked as a duplicate of this bug. *** |