Support opening native databases without importing. In large percentage it's a wish for KDb but there are subtasks for Kexi too. Note: If kexi__ tables are created in-place, the result stays backward compatible. Compare with wish #125843 "Add support for importing native SQLite 3 databases". Such change fits to Kexi 4.
sounds like a plan, to me, both wish is the same. i want to work with sqlite files in Kexi thanks for keeping this wish alive i look forward trying it out in beta
its weird how there is the ability to import a DB from a MySQL or PostgreSQL server. but if I choose to import from a file, there is only JET DB and .tsv isn't sqlite similar to what you are already doing? by the way, I could submit separate bug reports if you are interested but I tried importing 2 different MySQL DB, it failed both times. from PostgreSQL, it worked, except for unrecognize column types. uuid type mostly. hitting ok/cancel on a few dozens dialog popup of different size is bad UX. i don't know if you could gather those questions and ask to set them all at once?
IMHO public | kexi__db | table | postgres Create on open if missing. public | kexi__parts | table | postgres Create on open if missing, make it optional if possible. public | kexi__userdata | table | postgres Make this optional, create on first necessary write public | kexi__blobs | table | postgres Make this optional, create on first necessary write public | kexi__fields | table | postgres Default should load from standard tables, create table on first necessary write. aka, make it optional public | kexi__objectdata | table | postgres its empty, make it optional, create on first necessary write public | kexi__objects | table | postgres refresh content on open, or obsolete this table
> its weird how there is the ability to import a DB from a MySQL or PostgreSQL server. but if I > choose to import from a file, there is only JET DB and .tsv isn't sqlite similar to what you are > already doing? Thanks for the feedback Mathieu. For historic reasons, when we started to use SQLite (2) in 2004, it was more likely that user has MySQL or PostgreSQL database than SQLite file. Not we do admit native SQLite is very popular too. The logic of migration is very dependent on specifics of the source database format. Those specifics include what types are available natively (SQLite is very different there, liberal though type affinity), how primary keys work and what SQL constructs are supported. When we started to migrate foreign keys were not present or were not stable. > by the way, I could submit separate bug reports if you are interested but I tried importing 2 > different MySQL DB, it failed both times. from PostgreSQL, it worked, except for unrecognize column > types uuid type mostly. hitting ok/cancel on a few dozens dialog popup of different size is bad UX. > i don't know if you could gather those questions and ask to set them all at once? Yes please submit bugs separately if you can. Smaller, separate bugs, more chance they will get fixed separately. Large and general reports are harder to handle in our limited time. Of course you can report even most ambitious wishes, we need them noted down so nothing is forgotten or reported/discussed twice. > public | kexi__db | table | postgres -- Create on open if missing. I see you got this right. This is the same logic I planned to use to open native databases directly. That would be Kexi 4's format. One extra option to consider would be a compatibility with Kexi 3. We would have to always create all kexi__* tables, even those that you correctly mentioned can be optional. This way Kexi 3 can open the databases as soon as they at least once were "implicitly migrated/adapted" using Kexi 4. Such option can be turned off for users that do not need to care about compatibility with users of Kexi 2 or 3. Thanks again!