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.

Wayne

kexian wrote:I'd like Kexi to have easy to use calculated fields so I can use it for business.

Wayne

Yes, that's top priority because adding this feature immediately adds so much value. Techically, the idea is to start by narrowing the languages selection and offer javascript for calculations in any place that is suitable for calculations (Qt Script in Qt 4, soon Google V8 from WebKit in Qt 5).

Updated again at 21.48

Re calculated fields.
There are two ways of doing calculated fields.
On queries you can pass the calculus to the database server as most (even sqlite) can process them on a select query. Sadly no two DB engines have the same set of functions nor the same syntax, but a way to "pass thru" the evaluation to the DB engine would be welcome at times

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 ?
OTOH, I supose Calligra Sheets and Kexi will share the same function library, plus minus wrapping (Again the problem domain problem, a cell, a list or a selection have more or less direct translation on concepts on the DB side; but for usability reasons they MUST be converted)

Regards
Werner Llácer

Things I really miss- by now- in Kexi (or don't know how to do):

IMO the most important feature I miss - I'm most on the Data Analisys side of the tool- are the cross-reference queries (aka data trasposition, aka list inversion), with hierachization and aggregate functions. Corporate SQL tools in this regard are very weak to non existant, and understandably so. MS Access tools were very good at it(while with some rough edges). Excel's suffer from the clumsy interface ...

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.

To have more than one relationship between two sources in a query. At least i could not. Without this even a simple schema like :
Communication(fromParty,toParty, ....)
Party(id,Name, ...)
can not be properly queried

Less critical but is formally important, and is the posibility to change the cardinality and optionality of the relationships at the gui editor level(even the posibility of defining outer joins). But please, don't copy Access ...

Regards
Werner Llácer

wllacer wrote:Updated again at 21.48
Re calculated fields.
There are two ways of doing calculated fields.
On queries you can pass the calculus to the database server as most (even sqlite) can process them on a select query. Sadly no two DB engines have the same set of functions nor the same syntax, but a way to "pass thru" the evaluation to the DB engine would be welcome at times

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 ?
OTOH, I supose Calligra Sheets and Kexi will share the same function library, plus minus wrapping (Again the problem domain problem, a cell, a list or a selection have more or less direct translation on concepts on the DB side; but for usability reasons they MUST be converted)

Hi, Werner
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.

There is:
1. In-SQL-scripting
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.
2. Application scripting
2.1. formulas - mainly for ad-hoc calculated fields
2.2. full imperative scripting for adding business logic, also includes 2.1

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.
* in Kexi this would be the 1.1 approach, e.g. focusing on SQLite3 backend, we can declare functions for SQLite that in fact call code defined by Kexi's application scripting
* backend should support scripting of the same type (grammar, behaviour, extension/integration capabilities) as type of the functions in application scripting

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.

wllacer wrote:Things I really miss- by now- in Kexi (or don't know how to do):

IMO the most important feature I miss - I'm most on the Data Analisys side of the tool- are the cross-reference queries (aka data trasposition, aka list inversion), with hierachization and aggregate functions. Corporate SQL tools in this regard are very weak to non existant, and understandably so. MS Access tools were very good at it(while with some rough edges). Excel's suffer from the clumsy interface ...

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.

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.

wllacer wrote:

To have more than one relationship between two sources in a query. At least i could not. Without this even a simple schema like :
Communication(fromParty,toParty, ....)
Party(id,Name, ...)
can not be properly queried

Less critical but is formally important, and is the posibility to change the cardinality and optionality of the relationships at the gui editor level(even the posibility of defining outer joins). But please, don't copy Access ...

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.

jstaniek wrote:

wllacer wrote:Things I really miss- by now- in Kexi (or don't know how to do):
....

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 haven't been able to find a similar bug/wish so I added one https://bugs.kde.org/show_bug.cgi?id=299031

wllacer wrote:I haven't been able to find a similar bug/wish so I added one https://bugs.kde.org/show_bug.cgi?id=299031

I am sorry for not pointing out this quickly. It was reported at https://bugs.kde.org/show_bug.cgi?id=277869 before.

Two things I miss are:
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.

Thanks,
Kexian

kexian wrote:Two things I miss are:
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.

These are good ideas somewhat coming from spreadsheets world. I would propose following features as a first step:
* Arbitrary selections of the data table view (whole records and columns but also selected grid cells)
* 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).

Please let me create appropriate plans on bugs.kde.org. And do not hesitate to further extend the analysis here

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.
Couldn’t this adjustment be saved ?

I am glad to say this feature was added to Kexi 2.6 (pre-alpha) on September 1st:
- http://community.kde.org/Kexi/Plugins/T ... umn_widths
- https://bugs.kde.org/show_bug.cgi?id=230994

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"!

Thanks for the 2.5

For 2.6 I would appreciate to have the possibility to declare a form as "autoopen" when opening a project.