Kexi 2.4 release is planned soon within Calligra 2.4, so the feature set has been closed long ago. Not only that, but users of Kexi 2.4 except major GUI rework will see mostly bugs fixed and not many new features.
So I'd like to ask you what features are important for you. Please try to prioritize them if possible.
I think this project's TODO List may be helpful to what's already planned (even if delayed).
I'd like Kexi to have easy to use calculated fields so I can use it for business. Right now I have to use Lotus Approach, which has had calculated fields for over 10 years. I use Linux for the rest of my business but must go into Windows for an easy to use database.
kexian wrote: I'd like Kexi to have easy to use calculated fields so I can use it for business.
There are two ways of doing calculated fields.
If it is kexi engine which does the calculation you have to provide both an (albeit minimal) programming language/runtime and a function library. I understand that Kexi has to go forward on very limited development resources and to use an existing scripting environment is the best solution.
<<edited out. I've seen some of the samples in QtScript>>. I hope the narrowing down will not alter that much the DB access from inside the scripting. I would prefer the return to higher level -more problem oriented- aproaches to data base programing (at least on the abstraction level of PL/SQL ) as it was in (wonder) the late 80's and early 90's, but I understand the strictures of the project. Anyone knows of an open source equivalent of PL/SQL -or similar- as scripting language ?
Using queries as base for other queries. Underlying schemas/data tend to be complex, and having views -on many levels- to simplify or rebase on frequent selections is a real necessity.
Thanks for the accurate feedback. In-SQL-scripting is not the only one of scripting types that we'd like to have in Kexi. The other one is Application scripting. So let's start from the bird's view and summarize what know. Please note that below are just my random thoughts.
1.1. Backend-side in-SQL-scripting using the backend's capabilities. Pros: performance, reuse of non-Kexi projects. Cons: backend-specific due to lack of standards in this area.
1.2. Backend-side in-SQL-scripting provided by transformation (generation of SQL) from KEXISQL formulas to backend-specific formulas. There's no big performance overhead (except for small queries that are executed many times but this translation can be cached anyway). Pro: consistency across backends; Cons: feels foreign for existing non-Kexi projects; compared to 1.1 there may be feature for which transformation does not lead to the same semantics; in this case query of type 1.1. is needed.
1.3. Client-side in-SQL-scripting using the client (Kexi) capabilities common for all (or almost all) backends. Pro: backend-independent; Cons: extremely bad performance (executing custom function would require fetching all the result set); feels foreign for existing non-Kexi projects. Summing up: complete nonsense.
WISH 1: Merging the scripting experience of 1. and 2 is possible. This means function F(x) using in business logic should be available in queries as well (and would work properly unless - as side effect - they try to access application objects that are of course not available at the backend). MSA goes this way.
WISH 2: we don't want to limit users so having support for 1.1 is valuable. Backend-specific scripting such as PL/SQL would be available within native "pass thru" queries, explicitely marked as such. This lets the user to see clear separation between types of queries, and would improve self-documenting aspect of Kexi db app projects. Native "pass thru" queries are usable not just to use specific formulas but also for any specific SQL element (or specific semantics).
WISH 3: Sharing the same function library by Calligra Sheets and Kexi. That's the plan, relatively easy to deliver for application scripting. For SQL, addressing the WISH 1 is needed first.
Yes, Kexi as analytic tool is one of the eventual use cases. Especially strong (generic, extensible) table view is needed for that, and reworking it for Qt4 and 5 is still only planned. The bright side of this: we can use the newest features the frameworks offer (QGV or QML, enabled acceleration). Features we'd like to have include: conditionally coloured cells (feature merge with Calligra Sheets welcome), expanding records (so related data is visible in a tree branch as introduced in various tools, and in MSA since 2000), preview of DML query execution.
More or less does this mean inserting the same table into the Query Designer more than once? If so there is related wish on bugs.kde.org.
I am sorry for not pointing out this quickly. It was reported at https://bugs.kde.org/show_bug.cgi?id=277869 before.
1. The ability to duplicate records. If I need to create 10 records that are identical except for one field, it would be nice to be able to duplicate the first record 10 times and then just change the one field in each record that is different.
2. The ability to change all of the data in one field of a query with one command instead of having to do it one at a time to the specific data field in each record of the query.
* Copy, cut and paste for these selections. These actions could be of course far more complex in the long term (read: "intelligent") than usual text-based clipboard actions. For example pasting record that contains unique values is possible only if we have ability to deal with uniqueness (by asking user for filling out the values and/or automatically doing that by Kexi).
* For the 2nd request, some kind of macro would be useful or support for UPDATE type of functional queries (feature planned years ago).
Tables and queries open with equal width column, hand adjustable.
Couldn't this adjustment be saved ?
Robert Leleu wrote: Tables and queries open with equal width column, hand adjustable.
Another reason to be on the bleeding edge - compiling newest Kexi, so-called 'master' version.
PS: Feature plans for Kexi are always at http://community.kde.org/Calligra/Schedules/Feature_Plan#Kexi.
In particular, "Add support for alter table's design without losing data"!
For 2.6 I would appreciate to have the possibility to declare a form as "autoopen" when opening a project.