In relation with this bug, it is a non confirmed bug. May be a problem that the reporter has in their computer. I haven' t had this pb and I work with Base and Writer opened many times. Any case I don't think it is a blockerHello Juan,
There are also old bugs which aren't enhancements which are not fixed:According to TDF#51780 <https://bugs.documentfoundation.org/show_bug.cgi?id=51780> /(Database-Firebird-Default) - [META] Default to Firebird not HSQLDB in Base (for new_files)/, there currently do not appear to be any bugs that actually affect the functionality of the Firebird database engine. Most are enhancement requests to take advantage of capabilities that Firebird has that do not exist in other databases or are implemented in a different way
This one, although could be useful, as it is said in the comment #10 " there's no driver in connectivity which implements this. But let's say Firebird would be the first one", so we can survive without solve it (although, of course it would be very interesting to solve)
As the Firebird Language reference says "It is not possible to convert an existing column to an identity column, or to convert an identity column to a normal column. Firebird 4 will introduce the ability to convert an identity column to a normal column", so this bug is not a bug, but a limitation of Firebird. Surely it is possible to show better message when somebody try to modify it, but also, I think is not a blocker.
This one, in my opinion, is not a bug, but a request of enhancement. In the workaround there are shown solution if you need the value. The solutions are very similar to the solutions used with MySQL/MariaDB for example. ><Interesting to solve, any way
Totally agree. I hope @taichi can finish the work that is doing (unfortunately I don't have the knowledge to help)...
Moreover
1) we still use FB 3.0.7 whereas 2 major releases have been published (4 and 5) and version 6 is in dev.
At minimum, we should upgrade to version 5 to avoid trying to fix bugs on a old FB version.
2) what about the existing odb with HSQL Embedded, should we propose migration towards FB each time knowing there are still quite some bugs about it?
we may also stop proposing to migrate but then we need to maintain HSQLDB in addition to FB.
As already said, we should maintain the migration process, but as an option, at least not asking every time.
I think that HSQLDB should be remain together wit Firebird as
embedded databases
As I said, I think that put Firebid out of experimental mode can attract more developers to work on Base. I'll be my best, but as you already has seen I'm not a good developer, or better said I'm no a developer at all
3) there are not a lot of bugs about FB LO implementation per se because it's experimental but we may expect a fload of them if FB is not experimental again => who will take in charge the fload ?
Lionel is the only expert indicated in https://wiki.documentfoundation.org/FindTheExpert and he's not very available (I don't blame him, events in life often change your priorities, sometimes against your will)
Since Collabora and Allotropia hired most of the historical/experimented devs, if the customers of these 2 companies aren't interested for FB support, I suppose their devs won't have time for this.
So IMHO I'd let FB experimental except if someone is volunteer to work on the related bugs.
Julien
Remark: I put Lionel in cc as the Base expert dev and Robert+Alex Base expert for QA part.
Regards
