Re: [Firebird-devel] Directory aliases
08.04.2016 17:42, Alex Peshkoff wrote:
> This problem can be solved adding aliases for directories. Directory
> alias has directory separator symbol in the end of the name, like this:
Think wider, implement regexp aliases:
> group/* = /path/to/databases/$*
> {
> Key1=ValueX
> Key2=ValueY
> ...
> }
> Implementation.
> Requires modifications in single function expandDatabaseName(), i.e.
> should not delay FB4 release.
This function is already changed quite a lot in
https://github.com/aafemt/firebird
Feel free to create a pull request.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Directory aliases
I suggest one small addition to databases.conf in FB4 - aliases for
directories.
Existing method to set aliases in a form:
alias = file
{
Key1=ValueA
Key2=ValueB
...
}
has serious disadvantage - it's hard to provide and support
configuration for a large set of databases that should have same
configuration, also it's impossible to configure something for an
unknown in advance, able to grow set of databases (for example when new
databases in that set may be sometimes created by client application).
This problem can be solved adding aliases for directories. Directory
alias has directory separator symbol in the end of the name, like this:
group/ = /path/to/databases
{
Key1=ValueX
Key2=ValueY
...
}
When client tries to attach to database with a name starting with group/
(CONNECT 'group/some.fdb';) name will be expanded to
/path/to/databases/some.fdb. And any database in group/ will have same
per-database configuration values including a case when someone wants to
CREATE DATABASE 'group/newdb.fdb'.
Backward compatibility.
If someone has in databases.conf alias looking like directory alias
alias/ = /some/db.fdb
we may still resolve it in old manner - expand 'alias/' into
'/some/db.fdb'. If such file exists and it's not a directory attach will
succeed. An attempt to use alias in invalid way will in any case cause
an error "Is a directory"/"Not a directory" depending upon what was
attempted.
Certainly first of all passed from client db_name is checked as file
alias and only after it as directory alias, i.e. if in addition to
group/ = /path/to/databases
we have file alias
group/db1.fdb = /other/place.fdb
or even
group/db1.fdb = /path/to/databases/db1.fdb
but with another configuration it will be used if user connects to
'group/db1.fdb'.
Implementation.
Requires modifications in single function expandDatabaseName(), i.e.
should not delay FB4 release.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Feature request & discussion for V4 (same as for V3)
Hi Dmitry! Hope never dies. I prefer optimizations over the other new features. ;) Thanks for the reply. On 2016.04.08. 12:30, Dmitry Yemanov wrote: > 08.04.2016 12:54, Molnár Attila wrote: >> Here is my list. > List of v4 features is already composed. We may add some more > improvements here and there, but no promises about them. > > > Dmitry > > > -- > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Feature request & discussion for V4 (same as for V3)
08.04.2016 12:54, Molnár Attila wrote: > > Here is my list. List of v4 features is already composed. We may add some more improvements here and there, but no promises about them. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Feature request & discussion for V4 (same as for V3)
Hi *! Here is my list. DOMAIN OF COLUMN . - should work like TYPE OF COLUMN, but CHECK and NOT NULL constraints are checked when value assigned to this variable - gain : performance (allows early check, error raised before the actual DML statement run) SIZE OF riable name>, SCALE OF - SIZE OF : returns max CHAR/VARCHAR length or NUMERIC precision, SCALE OF : return scale of NUMERIC - gain : by defining a variable with DOMAIN or TYPE OF (or DOMAIN OF) the declaration is dynamic. But the in the PSQL body there is no dynamic access to this information, you still need hard code these values. With this you can avoid hard coded constants. ARRAY TYPE (only in PSQL) - static and dynamic, one and multi dimensional - gain : performance (no need for table write storing temporary data), shorter and easy to understand PSQL code (UDF parameters with array types?) RECORD TYPE (only in PSQL) - gain : shorter and easy to understand PSQL code (UDF parameters with record types?) TRY-FINALLY - gain : code reduction (Now with AUTONOMUS TRANSACTION it make sense to have try-finally structure. Currently I have the same code in the successfull run path and also in the WHEN ANY path) TRIGGER : NEW/OLD values accessible by column name, and column number (PSQL) - e.g.: NEW['id'], NEW[0] - gain : code reduction, dynamic code (don't have to alter the trigger ICO the table structure altered) Optimizations - CORE-2589 - CORE-2589 - CORE-4266 (please rename the ticket : "NULLS FIRST/LAST should not cause index loss") - IS NOT NULL should use index. It is equivalent with >= min_value or <= max_value based on index direction - condition pre-evaluation and reduction. e.g.: WHERE 1 = 2 AND field = :param is always FALSE. Evaluation does not needed for all records, can decide at prepare time whether the result is an empty resultset or an unfiltered resultset. - use index in "NATURAL" mode when column in a conditional appears in a multi column index, but not in the first place. You may reduce number of database page visits in this way : index page can hold more effective record data beacouse it's narrower than the table data page record (also in worst case it could be worse than NATURAL beacose ot the mixed index and table data page read, but I think overall it could worth it, especially in big tables. measurements needed) - SELECT DISTINCT FROM table is slow (natural scan on all records) and SELECT FROM table GROUP BY is also slow (worse! : index scan on all records). I think in this case it's not neccessary to read all the records in the table, it should be enough to read #of distinct values from table. (currently you have to keep a separate table with this information because you can't access to this information fast) Thank You! -- Molnár Attila szoftverfejlesztő Libra Szoftver Zrt. 1113 Budapest, Karolina út 65. Tel.: +36 1 255 3939 Fax: +36 1 209 1477 http://www.libraszoftver.hu Tisztelt Ügyfelünk! Tájékoztatjuk, hogy 2015. október 14-től megújult a Libra Groupware, a Libra Szoftver Zrt. bejelentő rendszere. A rendszerhez, korábban már regisztrált ügyfeleink új jelszót a https://libragroupware.mve.hu/lgw/ link használatával kérhetnek. Új regisztráció a regisztra...@mve.hu címre írt levélben igényelhető. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
