Remove the System Domains from the domain node about flamerobin HOT 12 CLOSED

The current query to get the domains is this:

select 
             f.rdb$field_name,            --  1
             f.rdb$field_type,            --  2
             f.rdb$field_sub_type,        --  3
             f.rdb$field_length,          --  4
             f.rdb$field_precision,       --  5
             f.rdb$field_scale,           --  6
             c.rdb$character_set_name,    --  7
             f.rdb$character_length,      --  8
             f.rdb$null_flag,             --  9
             f.rdb$default_source,        -- 10
             l.rdb$collation_name,        -- 11
             f.rdb$validation_source,     -- 12
             f.rdb$computed_blr,          -- 13
             c.rdb$bytes_per_character    -- 14
         from rdb$fields f
         left outer join rdb$character_sets c
             on c.rdb$character_set_id = f.rdb$character_set_id
         left outer join rdb$collations l
             on l.rdb$collation_id = f.rdb$collation_id
             and l.rdb$character_set_id = f.rdb$character_set_id
         left outer join rdb$types t on f.rdb$field_type=t.rdb$type
         where t.rdb$field_name='RDB$FIELD_TYPE' and f.rdb$field_name not starting with 'RDB$' 
         order by 1

I imagine a additional filter for Fb>3 would solve it:
and f.RDB$SYSTEM_FLAG=0
Or if this field is available since Fb 1.5 the check wont be necessary, I'll need to verify it

from flamerobin.

Unfortunately the method std::string Domain::getLoadStatement(bool list) is static, so I won't have its database info without changing some more lines of code, this way, I'll hardcode the proposed change without verifying server version or db ODS
Any other idea? Else I'll pull the patch

from flamerobin.

Hi @arvanus

In my honest opinion if it is not possible to make a fix without breaking compatibility with Firebird 1.x we should create a branch for Firebird 1.x (e.g.: firebird_1_x) and continue the development of the FlameRobin for Firebird 2x/3.0 in the master branch.
The Firebird 1.x is very old and probably the systems that still use it also use an old version of FlameRobin and they probably don't think about updating it.

What do you think?

Best Regards,
Luciano

from flamerobin.

Hi, I simply copied intlemp.gdb example from Fb 1.0, and opened in my Fb 2.5 server... and rdb$fields.RDB$SYSTEM_FLAG field is there in the database, so it's probable that this change won't break compatibility with Firebird 1.0
I'm not sure 100% sure, but I bet it's OK 😃

Also I'm not 100% familiar with git at all, but I think that a tag "FIREBIRD_1_DEPRECATED" or something like that would be enough, because with a branch it would be there "forever" pending annoyingly 🤏 😸
What do you think?

Of course if someone could kindly test in a Fb1.0 environment if could be great!

from flamerobin.

Hi @arvanus

A branch for Firebird 1.x only makes sense if we are willing to continue developing and maintaining FlameRobin support for Firebird 1.x.

If we decide that from now on we will only develop and maintain support only for Firebird 2.x / 3.0 / 4.0 we can:
1- Create a tag for the latest version of FlameRobin that supports Firebird 1.x (FIREBIRD_1_DEPRECATED as you suggested);
2- Continue the development in the master branch supporting only Firebird 2.0 and newer;

To be honest, it would be more productive for all of us to only support Firebird 2.5 / 3.0 / 4.0. This would reduce our development / testing effort and thus we would be able to quickly implement the new features in Firebird 3.0 and 4.0 and other interesting features.

Once again, thank you very much for your work and support on this project!

Best Regards,
Luciano

from flamerobin.

Firebird 1 is loooong deprecated, sorry for the folks that still use it
I suggest to deprecate 1.0, create a tag and move forward

About 1.5 it would be better to ask the users if anyone still uses it and is willing to help and test...

@mariuz what do you think?

from flamerobin.

Firebird 2.0 or Firebird 2.5.x is what we should support as minimum for the moment https://firebirdsql.org/en/roadmap/

The project's development resources are currently dedicated mostly to the v3.0 and v4.0 development. Firebird v2.0 series has been discontinued in 2012, the last release in this series is Firebird 2.0.7. Firebird v2.1 series has been discontinued in 2014, with Firebird 2.1.7 being the last release there. Firebird v2.5 series was recently updated with the Firebird 2.5.9 release and is also discontinued now.

from flamerobin.

you can also use previous releses and tags for firebird 1.x if neededd

from flamerobin.

I totally agree with you @mariuz!
Let's focus on the development and fixes for Firebird 3.0.x and before publishing the commit we tested if it did not introduce any side effects in Firebird 2.0.x.

Best Regards,
Luciano

from flamerobin.

By the way, has this issue been fixed yet? If the c75ea10 fix did not introduce any side effects in Firebird 2.x I think we can close this issue. Do you agree @arvanus?

from flamerobin.

@arvanus could you make a pull request from arvanus/flamerobin ?

from flamerobin.

Done

from flamerobin.