Re: [Firebird-devel] Ability to use non-local protocol to create DB which alias is declared as self-security
Hi, Dne 09. 08. 22 v 17:02 Alex Peshkoff via Firebird-devel napsal(a): *Pavel & Pavel!* I understand you have some problems with testing system due to unablity to create self-security database remotely. But I do not understand how could as solution be suggested not to check credetioals at all, i.e. let everyone create databases. That's like let everyone atach to server and enter SYSDBA password when security database failed to proper initialize at install phaze for some reason. We used to fight for FB security for many years (almost twenty) and it's very strange for me to here such suggestions. We added special privilege for create database in order to avoid creation of databases by regular users. And after it suggestion to let do it everyone - at least for some databases... I did not suggested to do not authenticate user! My question was why user has to be authenticated AGAINST YET TO BE CREATED database. It simply doesn't make sense at all for me. I would expect that for create database, the user would be authenticated in the same way as for attachment to service manager. The reason is that user does not need to have any prior valid attachment to call create database, so credentials passed for create database should be used to verify that such database could be created for that user, but not the database specification itself! It should be used for connection to created database, but not for creation. It's IMHO illogical that setting for not yet created database are used to do that (which fails when created db is self-security) instead default security database. The creation of self-security db via local (i.e. bypass of authentication check) is IMHO a hackish workaround that beats the purpose of security, because self-security databases could NOT be ever created in insecure way. I can think about letting user, authenticated in default security database with appr.privileges, create self-security databases remotely. But definitely not what was suggested. Yes, that was suggested, just probably wrongly worded. I though that when referencing that right to create database should be checked in the same way as attachment to service manager (which does not use some database reference passed by user to decide which security db to use) instead database that does not exists yet is quite clear. best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Ability to use non-local protocol to create DB which alias is declared as self-security
Hi, Dne 09. 08. 22 v 6:33 Alex Peshkoff via Firebird-devel napsal(a): Why this restriction exists ? Because login / password to be validated in the database that does not exist yet. Therefore password check fails and you can't attach to server. Without connection to server it's hard to create something on it ;) I really don't understand WHY it's necessary to authenticate user against some database for *create database*. It's definitely not necessary to provide any kind of database reference to attach to service manager. I understand that create database also works as connect (i.e. returns attachment to database), so it will use the same credentials for such connection to created database in normal way, but to authenticate the right to invoke the database creation itself, no database should be needed (like it's not needed for attachment to service manager). best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Status of 3.0.10
Hi, because 3.0.9 has significant regression (#7137 - we've got multiple reports from large affected and unhappy users), I'd like ask what are the prospect to release v3.0.10 soon. BTW, it would also address contracted collation performance issues that we hoped would be addressed by 3.0.9, but as 3.0.9 release was rushed ahead of schedule, this was deferred to 3.0.10. regards Pavel Cisar IBPhoenix Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] New development re. "contracted" collations and new QA
Hi all, I'd like inform you about new developments regarding: a) performance issues with partial key lookup with "contracted" collations. We've got sponsor to implement Adriano's solution using 3.0.8 code as primary target. The development and testing should happen in next three months. If everything will go well, the pull request with verified solution would be ready for review in early April (or end of March). We hope that it would be accepted for merge into 3+ branches. b) New QA based on pytest We have finished conversion of the whole tests suite from fbtest to new system (incl. changes in fbt-respository up to 31th December). About two hundred of tests still wait for reimplementation or decission about their fate (mostly those that depend on changes to firebird configuration or external tool like encryption plugin etc.), but the majority of test suite is functional and robust. This means that phase one is finished and we entered phase two - the real transition to new QA system. For some time, both QA systems could / would be operated in parallel, with a target to fully deprecate the old system for testing FB 3, 4 and 5 this summer (or sooner if possible). At this point, development or update of tests in old system is possible but discouraged to streamline and speed up the transition. best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] UDR for reading server configuration for Firebird QA
Hi all, our test suite contains many tests that depend on specific server configuration settings (mostly related to security, encryption, pools, timeouts, transactions etc.). As these configuration requirements may contradict each other, it's not possible to create single firebird.conf that would satisfy all tests. While the number of such tests is small, it's not marginal either. Now such tests fail (in best case) when requirement is not met, which spoils the QA run results when whole suite is run, or they have to be explicitly excluded which further complicates the management of QA runs. As it's hard for us to automatically change the firebird.conf and restart the server quickly and reliably on all platforms, we couldn't run each test with its own engine configuration specification. It would also complicate automated testing on our build systems. So, instead this I'd like add the ability to check tested engine configuration to our QA tool set (pytest plugin), so tests could be automatically skipped if their requirement is not satisfied. On FB v4+ it's easy, thanks to RDB$CONFIG pseudo-table. However, on v3 it's not that simple. I thought that I could use iMaster.get_config_manager() -> iConfigManager.get_firebird_conf() -> iFirebirdConf for that, but it does not work from client side (reads client config, so it works only with embedded). To make it work for remote access, we would need UDR that (according to Vlad) should be able to query master interface and get current config. We don't need anything complicated, just one function that would get configuration option name (string) and returns it's value (NULL or string [VARCHAR?]). But here we run into two problems: 1) Although it should be simple UDR, it's out of my area of expertise and I'm not able to create it myself. 2) It should be part of Firebird 3 build process and stored in /plugins/udr like udrcpp_example is, so it could be used by QA. Alternatively, we can simply skip such checks for v3 and skip these tests unless some env variable would have certain value, which could be also workable solution (although less convenient). In fact, if v5 would be really released next year (rendering v3 obsolete), it could be the simplest solution. What is your opinion? Which route we should go? best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Plans for 4.0.1
Hi all, would be 4.0.1 released in December, January or later? regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: RFC: Fix for issue 6915
Hi, Dne 05. 11. 21 v 12:54 Alex Peshkoff via Firebird-devel napsal(a): Pavel - how this SHOULD be in firebird from big clients POV? STARTING WITH "HROC" should return only HROCENI or HROCH too? They prefer that "C" should NOT match "CH" (which is also how Oracle and SQLServer do it). Fact is, that if the pattern ends with "C", it's ment as "C" and not "CH". If user wants to look for "CH", it's defined explicitly as such, i.e. trailing "C" is never "unfinished CH". regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: RFC: Fix for issue 6915
Hi, Dne 04. 11. 21 v 16:56 Karol Bieniaszewski napsal(a): „The main reason why this "removal of trailing partial contraction" was done is to achieve behavior "consistent" with search/evaluation in other software (like text editors etc.), so (for example) STARTING WITH "C" or LIKE "C%" will return rows starting with "C" or "CH". This behavior itself is questionable (but more about that later) „ I try to understand the issue but meybe simpler description is required. When i use WIN1250 collate PXW_PLK (my Polish language) Then engine threat all „ch” as single letter in the index? And i cannot find looking by only „c” without „h” with index lookup? If yes how engine decide that this is „ch” or „c” and „h” in words? This is one from dark, messy corners of IT like time zones... First and foremost, Polish language AFAIK does not define "CH" as separate letter (or use any other contractions), so this issue does not affect PXW_PLK (or other Polish collations) at all. Collations are primarily used to define order. Contractions and expansions are special rules that allow to treat groups as units or units as groups for ordering purposes. For example, Czech "CH" letter is ordered between "H" and "I". Unfortunately, it's not defined as single letter in most character sets. Although there are charsets like KOI-8 CS2 that have it, it's not defined in ones that are really used (i.e. pushed by dominant players like Windows OS). Czech IT settled on use of WIN1250 or ISO-8859-2 that does not define "CH" as single letter, so proper order of "CH" depends on collation "contraction" rule. Collation is used to produce "sortkeys", which is basically transformation of given key to binary sequence that could be compared directly (bytewise) with other sortkeys. In RDBMS, the sortkey is used for all sort operations, and for index keys (as they also rely on comparison as it's binary tree). The same apply for comparison predicates (i.e. col >= value etc.). The problem is, that when you look up for partial key that ends with a character that is start of contraction, you enter somewhat gray territory. For example: The key "HROCH" (Czech word for hippopotamus) could have sortkey: 13+27+23+14 (each letter replaced with byte representing it's order place in alphabet, which is simplification for this showcase, i.e. 13=H 27=R 23=O 14=CH) If you would look for STARTING WITH "HROC" (or LIKE "HROC%"), you have a partial key that would transform to sortkey: 13+27+23+4 (4=C) which will not match "HROCH", but match "HROCENI" (roaring). This is actually correct from Czech language POV, but not from IT POV when you work on character level of characters defined in charset. Firebird currently "solves" that by removing the trailing partial contraction from sortkey, i.e. it will return sortkey for "HRO" instead for "HROC", so keys like "HROCH" or "HROCENI" are matched. Sure, it may match also keys like "HROB" (grave), but these are latter eliminated from result set by final expression evaluation. Remember, that index lookup just collect candidates that are then read and verified by expression evaluation (necessary step due to MGA). As you can see, this approach leads to excess I/O. The scale of additional I/O depends on your data, and is highly influenced by character set - UNICODE/UTF8 requires more storage space, which means that the same number of rows could occupy much more data pages (in some cases significantly more). However, the Czech language defines only one contraction (CH), but there are other languages that have many such as Hungarian. Btw, if you are interested in collations, take a look at https://collation-charts.org/ best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: Fix for issue 6915
Mama mia, here we go again.
I have no intention to get sucked even deeper into this endless
discussion. I'm fighting covid right now and really don't feel fit for
it. In fact, I personally don't care HOW this will be fixed, as long as
it WOULD be fixed in some timely manner, which is obviously and sadly
not going to happen.
If it would be on me, the best fix would be fixing physical storage
inefficiency for UTF8 data. The "contraction" problem is in Firebird for
long time, and it wasn't real performance killer until everyone keeps
with NARROW charsets (proven by tests). It's the UTF8 storage
inefficiency that blows this out of proportions (also proven by tests).
Everyone knows that this is the real problem that hurts the performance
in general, and there was a push from users to solve that for many
years. There was even new RLE code from ElectLabs to solve it, and
although it was not accepted - as far as I remember - a solution was
promised by project. Six years later, we still got nothing (I and see no
such thing on v5.0 roadmap so go figure).
Now this failed promise bitten us back as another unhappy Firebird user
(one from big Czech software houses that uses Firebird from day one)
that needs to switch hundreds of databases of its big international
customers from codepages to UTF8 in Q1/2 next year got stuck as
extensive testing revealed serious performance issues after switch to
UTF8 ("contraction" issue is just the biggest performance loss spike, so
they bring it to our attention). They are even willing to pay to get it
solved, but as months pass, it's more and more obvious that they will
eventually end as dead in the water (no solution in due time). Guess
what? As they are under pressure themselves to do the switch, they will
have to start move away from Firebird for important big projects (no
kidding). They will certainly keep it for low end as it makes sense, but
anyway.
Maybe I'm just getting old and worn by mounting waste of time and
effort, but it appears like the project is slowly but surely losing its
drive and spirit over years, as it more and more feels that we're
running to stand still.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] RFC: Fix for issue 6915
CONSISTENT with how MS SQLServer and Oracle handle these cases (which we verified). This fact was highlighted by asked users (that often build applications supporting multiple RDBMS) as another reason (beside that it's how it has to work in first place) why this solution should be the preferred one. IF we will implement this solution, we will introduce configuration option to switch between new and old behavior. If this will be done in point releases, it should be *disabled* (old way) by default and enabled explicitly via config option. v5 may have this enabled unconditionally. 2. Solution (proposed by Adriano): Replace the trailing partial contraction removal code with code that would make multiple lookups for all parts of possible contraction, for example STARTING WITH "C" will perform lookup for "C" and "CH". Experiments show that this should also solve the performance problem, while keeping the current behavior. However, the current behavior is not exactly what asked affected users want. Here is the opinion from Dmitry Yemanov: I'm not really happy with comparing only to Oracle/MSSQL. MySQL seems to be in the opposite camp and agrees on 'ch' like 'c%' is true in their utf_czech_ci collation. PostgreSQL is somewhat difficult to compare against, as AFAIR it still relies on the system locales and does not have any built-in collations. And regardless, I give more priority to the "natural language" argument than to the "compatibility" one. However, it's good when they match each other. For me two things are obvious: 1) Regular comparisons (as well as sorting) must use all collation rules, including contractions 2) There should be no difference (except performance) between indexed and non-indexed access But the rest is really complicated for me. We had INTL support for kinda everything, but SIMILAR was implemented later and uses a different rules. Maybe in the ideal world it could also take collations into account, but we're surely not in position to do that ourselves, and given that no other DBMS seem to have collation-aware SIMILAR, let's just consider it a fact we live with. LIKE and STARTING WITH are in the middle between comparisons/sorts and SIMILAR though. If we treat LIKE being a close friend for SIMILAR and STARTING WITH being a shorthand for LIKE, we may end with both ignoring the collation rules. If we treat STARTING WITH as a custom shorthand for greater-or-less comparisons, then it should be collation-aware. For me, the former thinking is more logical. But STARTING WITH is non-standard so we are free to implement it the way which is more useful for customers. What is really questionable to me is whether it's OK to divorce STARTING from LIKE re. collations, given that internally they are closely related (LIKE may be backed by STARTING). Is it possible that internal STARTING (which thinks that 'ch' does not start with 'c') would break the user-specified LIKE which expects the opposite behaviour? If both STARTING and LIKE would respect contractions, then the only problem remaining (*) is LIKE vs SIMILAR mismatch, but personally I consider it a lesser evil (see above). (*) I see SUBSTRING/REPLACE/CHAR_LENGTH as different class citizens, thus intentionally ignore their inconsistency with LIKE/STARTING. As for Adriano's suggestion with multiple lookups, I don't see it as a problem. It looks hackery at the first glance, but it solves the original performance issue and I suppose it could even be improved (with more efforts, of course) to use a single scan for multiple matches. But it makes STARTING to consider 'ch' like 'c%' is true what AFAIU our customers don't really want and this is the problem. --- As you can see, we were not able to reach final decision which approach should be used as either solution does not have majority or authoritative support. It's very unfortunate, as this issue is critical for (at least) one major Firebird user, so we need to select one and implement it as soon as possible. Hence we'd like ask you for your feedback about proposed solutions, so we could break this stalemate. best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Partitioning (was: Tablespaces proposal)
Hi, Dne 12. 10. 21 v 15:21 Dimitry Sibiryakov napsal(a): BACKUP: Backup of separate partition is something nobody asked for so far. At least I cannot remember a ticket for gbak accepting filter condition inside of a table, only filter for whole tables and (since it is already implemented)... is anybody aware of it?.. Actually, it may make a lot of sense. Imagine that partitioning is used to separate historic records to partitions by years (for example). As historic data are not changed, the current year is (new records), so it may make sense to backup only the "active" partitions. In light of that, it may be a nice feature if partition would have an "updated" flag, and gbak an option to backup only changed partitions. RESTORE: How backup of single partition is supposed to be restored or otherwise used? For gbak it does not really matter, as it restores what is found in backup file (he can't recognize that it's not complete source database). So user would get "partial" database which might be useful. For example it could be a way to move archive data, i.e. backup historic partitions and restore them to historic database for some analytics. It may also open an opportunity to create in-place restore for gbak. It would restore to existing database, replacing partitions found there with content of partitions found in backup file (would require unique partition ID). Certainly, using selective partition backup/restore must be paired with proper database design and partitioning to make it work properly, but it's certainly a nice tool for handling long-living databases and historic data management. best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6499) Regression: gstat with switch -t executed via services fails with "found unknown switch" error
Regression: gstat with switch -t executed via services fails with "found unknown switch" error -- Key: CORE-6499 URL: http://tracker.firebirdsql.org/browse/CORE-6499 Project: Firebird Core Issue Type: Bug Affects Versions: 4.0 RC 1, 3.0.7 Reporter: Pavel Cisar Found via firebird-driver that uses new OO API. When gstat is executed via services, the -t switch is passed via SPB tag COMMAND_LINE (105) followed by string containing '-t tablename'. This works just fine with firebird 3.0.5, 3.0.6 and 4.0 Beta 2, but fails on 3.0.7 and 4.0 RC1 with "found unknown switch" error message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Adriano, Dne 09. 07. 20 v 17:32 Adriano dos Santos Fernandes napsal(a): I prefer to base implementations on standard + competitors + common sense. So far from the standard pieces, Firebird follow standard. From the extensions pieces, Firebird follow competitor who implement same extensions, trying to be less weird than it. I have no problem to accept that (evolution of FB engine is not my responsibility) although I have my personal reservations to such approach. Standards are important but are often questionable and are subject of change as any other thing (saw many come and go or change significantly over my life). Competitors is a hard choice as one never becomes a leader by acting as follower, and one can blindly follow into the pit. I'd always pick common sense (i.e. real needs + simplicity + least surprise) as top rated value (that often leads to most elegant "actually used" solutions that may eventually become a standard by landslide and not by committee). For time being I'll do my best to mount round tubes on square holes. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Adriano, Dne 09. 07. 20 v 16:39 Adriano dos Santos Fernandes napsal(a): Storage apart, it still requires conversions to TIMESTAMP, comparations, etc work, so a base date is anyway required. Conversion to TIMESTAMP without providing the exact date explicitly is meaningless (as anomalies are numerous and result is not generally predictable) and shouldn't be supported. If TIME WITH TZ is a wall clock, then conversion to TIMESTAMP means that TIME is simply added to / joined with the date part. I.e. if I want value 12:30 in region A (taken from TIME WITH TZ) as timestamp for date 2021-06-31, then I mean it, no time recalculations should be done and the result should be 2021-06-31 12:30:00. I can't imagine what other return value would be good for. IF TIME WITH TZ is a wall clock, then comparisons between two TIME WITH TZ is like comparing two TIME WITHOUT TZ. Which makes sense and could be useful, other variants IMHO does not make sense. Then about storage, it of course make sense to store the UTC rebased value, as it's a -TZ type and it would make lot of sense to do it for offset-based TIME-TZ, so it should use the same storage semantics for region-based ones. From simple math point of view, it would make sense for offset-base TZ as it would allow you to compare whether some time is before another between timerzones. But practically doesn't, because comparison of two times in UTC without date don't get meaningful values for wraps at day boundaries (which is a lot of values). Using some deliberate date for recalculation doesn't fix the problem, unless you actually convert them to TIMESTAMPs for comparison itself. So doing the recalculation to UTC at storage actually does not allow you to convert it back to correct TIMESTAMP on comparison as the value is already skewed at day boundary. As this "usefulness" is limited only to simple offset-based timezones, it's IMHO not worth the effort as it would only cause confusion and problems in real world use when things (zones) get messed up in data. If one wants such comparisons, then TIMESTAMP (even casted to) should be used. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Dne 09. 07. 20 v 15:54 Adriano dos Santos Fernandes napsal(a): If OS is configured with deprecated time zone, it will return deprecated time zone name. I don't have my system configured to use deprecated time zone name. My /etc/localtime is a symlink to /usr/share/zoneinfo/Europe/Prague BTW, OpenSUSE (I use Tumbleweed) presents only named regions on setup to choose from. Europe/Prague is there in Linux. Yes, I know :) Please note that "/usr/share/zoneinfo/Europe/Prague" is a file that contains data about timezone region 'Europe/Prague'. If you'll inspect the content, I'll find that it refers to CET and CEST, and has no reference to 'Europe/Prague'. That's because some regions are aliases and hence symlinks to other files, hence it's not possible to get region name from the file content. You can't even use the filename, because it's not always applicable, for example local timezone is content of /etc/localtime which is a symlink. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Mark, Dne 09. 07. 20 v 13:47 Mark Rotteveel napsal(a): Again, it's not correct, it's just consistent/invariant across calendar. Please explain exactly which aspects are not correct according to you. If the goal is to produce a consistent value at a named zone, this is the only way to do it in a dateless type. The central point of our dispute is that TIME WITH TZ is pointless for calculation, so any recalculation you do on storage/retrieval just puts mud into waters even more. The TIME WITH TZ is just a wall clock at given region (24h cycle) + information of origin where (region) the wall clock was sampled. You can't compare times from two regions neither from the same region that has DST or other time-shifts, as the result is meaningless. Imagine you store time 20:35 in region that is UTC+02:00 and then you compare it to time 23:35 in region that is UTC+08:00. What meaningful information you will get? How conversion to UTC will help you to get any meaningful information out of it? The only meaningful information stored TIME WITH TZ is the association between wall clock and it's origin in single column. So, it should be stored as is (the actual value when it was sampled). When I sample 12:30 then it's 12:30 where I'm and it doesn't matter whether DST is in effect or not. The recalculation to UTC requires use of fixed date, so you actually remove the only one meaningful information - exact time + origin info, because you change the time I want to store, adding nothing useful. If I would need comparisons and calculations that make sense, I'd use TIMESTAMP and not TIME. The rule I described was for a *TIME WITH TIME ZONE*, not for a *TIMESTAMP WITH TIME ZONE*, so, given the limitations of *TIME WITH TIME ZONE*, the rebasing is necessary. I don't rebase to a different date when handling *TIMESTAMP WITH TIME ZONE* values. I see, I was mislead by fact that you rebase the date in datetime object as well. What I do is exactly what needs to be done to be able to consistently reconstruct a value, so instead what you claim without base that I consider it acceptable to have inconsistent data, that consistency is the cornerstone of what and why I do this (and to be honest, I kind of resent your implication that what I'm doing is shoddy work). The problem is that you look at it too technically from Firebird & driver POV, so you see your solution as correct one - because technically it is correct at this level. But from app. developer POV it's plain wrong, because what is stored is not what is read back under all conditions. App devs. don't care about Firebird's and driver's difficulties and methods, it's just a black box storage. Data can change format, but not meaning, and output time that differs from input one is not what one would expect or wants. The only difference is that when retrieving a ZonedDateTime (which is the only datetime type in Java that preserves named zones), I rebase to the current-date, to have similar behaviour as what Firebird does when casting TIME WITH TIME ZONE to a TIMESTAMP WITH TIME ZONE. On storing a ZonedDateTime, it does the same as what happens when casting a TIMESTAMP WITH TIME ZONE to a TIME WITH TIME ZONE. Again, you perfectly and correctly replicated the Firebird's (IMHO) senseless behavior of comparing apples to oranges. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Adriano, Obviously the problem is in impedance mismatch between ICU and other systems that use IANA timezone database (notably POSIX, can't speak for Windows). This is then moved to programming languages that typically use OS services to handle timezone information, and not ICU (which is just a library on host system). On POSIX/Linux, these data use separate time(zone) names for DST (as far as I can tell, I did not checked all of them). Historically, the time zones were hour-shifts from GMT, and regions/countries picked one (or more) to use depending on geo-location. These "picks" get names, so we've got Central European Time (GMT+1) etc. Some are retained till today, some were deliberately added or removed from systems (that's how we got "Arab Standard Time" and "Arabic Standard Time" (both UTC+3) and "Arabian Standard Time" (UTC+4) in Windows. The DST in some regions complicated it event more as it's a seasonal time shift to another time zone, but people will not use the "adjacent" timezone name so "summer" time was invented and we've got CEST and the likes. But DST is not the only one time shift in effect, it's just the most prevalent one. The DST made a lot of confusion among people and especially SW developers. Some retain a view / assumption that DST shift is applied to timezone as it's actually a shift in local time at usually uses some timezone, while others see it as temporary switch to another (adjacent) timezone (hence the different names) because the timezone can't "travel" because it's defined as fixed offset from GMT. Eventually we've got named regions that effectively pair shifts and switches in time zone (which is still a slice of global 24h defined by offset from UTC - former GMT) to particular region on Earth. This should fix the mess caused by DST confusion. And it eventually fix that, IF people will cease to use timezone names and use regions that "observe" timezones that are offsets from UTC. Timezone names like CET or CST6CDT are DEPRECATED (check that on wikipedia). Canonical names for timezones are those in "Etc/" for example "/Etc/GMT+2". The "funny" thing is that offset in GMT name is actually inverted offset from UTC, so Etc/GMT+2 is actually UTC-02:00. So, we still have a mess at our hands until transition will be completed. For example on Linux (and other POSIX) the timezone info for region still refers to timezones through old names like CET/CEST etc. when you ask for timezone in effect for specific timestamp for the region. On Windows it's even worse (see "arabian nights" example mentioned earlier). Now imagine the situation of poor developer who relies on prog. language library that typically uses host system facilities to deal with timezones. He gets what he gets. I solved the problem in Python driver by augmenting the tzinfo object with required (region) metadata, and it will work on POSIX if only regions would be used (which includes direct use of timezones in Etc/* range). The solution for Windows is still work in progress, hope I'll find a solution there as well. regards Pavel Dne 08. 07. 20 v 15:32 Adriano dos Santos Fernandes napsal(a): We will need to decide if we maintain things as is, will drop support from regions in TIME-TZ or will drop TIME-TZ completely. I personally think TIME-TZ with regions are a valid thing (albeit weird depending on the operations) because it fills a gap where one creates a TIME and a additional region column. TIME-TZ with offsets only (no regions) does not have the weird things by definition, but weird things will happen when converting from timestamps. The problem is that Firebird recalculates the time to UTC for storage, which means that some fixed date is needed for recalculation for regions, which may screw up the data. I would rather store the time as is than in UTC, so it will be actually a WALL CLOCK time + region info. The math / comparison of TIME WITH TZ between two regions is meaningless anyway, unless you consider it as wall clock times. I see two ways that time zones are handled: 1) Time zone name changes if the date is in DST or not 2) The one Firebird use, where time zone name does not change ICU does not seems to work in the 1 way. I also think not all software work like that, nor exists DST time zone names for every country/time zone. Certainly not all, but it's also not a marginal number. Globally, think 50:50 and you wouldn't be wrong by much. Do every software you use changes CET to CEST depending on the date? Windows? Linux? The browser? Anything that uses POSIX timezone database present on all POSIX systems (for example on linux it's in /usr/share/zoneinfo). What will happen if in Python you try to create a date not in DST using the CEST time zone? Or the contrary, a date in DST using CET? The problem is that I'll not create a date in CET/CEST, but in 'Europe/Prague' region. However, when I'll ask for timezone name needed by iUtil.en
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Dne 08. 07. 20 v 21:13 Mark Rotteveel napsal(a): On 08-07-2020 20:16, Pavel Cisar wrote: As I said, CET is a zone that has a DST rule, that means that - for example - on 2020-01-01, 12:30 CET is 11:30 UTC, while at 2020-06-02, 12:30 CET (== 12:30 CEST) is 10:30 UTC. CET is NOT a zone with DTS rule, CET (Central European Time) is 1 hour ahead of Coordinated Universal Time (UTC). This time zone is in use during standard time in: Europe, Africa. Some places observe daylight saving time/summer time during the summer, and therefore use CEST (Central European Summer Time) in the summer. So, timezones like 'Europe/Prague' HAVE DST rules where they switch between CET and CEST. For example Algeria and Tunisia have CET the whole year as they don't switch to CEST. And that is yet another reason not to use the short time zone ids, because they are ambiguous, the ICU time zone database does apply DST rules to CET: How ICU can apply DTS rules on CET? CET has NO DTS rules, only named zones (countries) can. CET is simply time that is UTC+01:00, period. So if ICU (and through it Firebird) defines DTS for CET, it's plain wrong. If it wouled be true and CET would have DTS rules, Algeria and Tunisia couldn't have it for WHOLE YEAR! However, the impression that CET has DTS rules could happen when library or system does use the same name for DTS shifts, i.e. uses only CET and does not recognize CET/CEST. In such case the UTC offset may differ while the name is the same. Other systems use different names to signal that offset differs (because DTS is actually a seasonal shift to another timezone). Both approaches (single name, different offset + distinct names for offsets) are widely used and acceptable. The single name + different offset approach is actually NEWER than multi-name and is still not the dominant or most significant. For example the POSIX systems (i.e. Linux) today use the multiname approach (and they also use the IANA timezone database). Please, read some documentation about the problem in general, not only documentation for libraries you (or Firebird) use to get unbiased view. And yes, it's a mess, but we don't live in ideal world. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
MArk,
Dne 08. 07. 20 v 20:51 Mark Rotteveel napsal(a):
Says who? Why 2020-01-01 and not other date? Because Firebird uses it
does not make it right, it just make it consistent with Firebird. Also
mind that DTS is just one from possible time shifts for timezone.
Yes, Firebird says so. Firebird and client applications need such a rule
because otherwise it is impossible to derive a consistent value for a
TIME WITH TIME ZONE value of a named zone.
Certainly, which is the point why TIME WITH TIMEZONE is pointless. It's
inconsistent in dependency on time zone. The consistency between client
and Firebird does not make it more consistent in behavior as data type.
In the previous situation (before snapshot 4.0.0.1954), a value stored
as '20:58:00 Europe/Amsterdam' would depend on the date it was saved: if
it was saved on 2020-02-01, it would be saved as '19:58:00 UTC' + zone
id of Europe/Amsterdam. If it was saved on 2020-06-02, it would be saved
as '18:58:00 UTC' + zone id of Europe/Amsterdam.
Which actually could be desired behavior in some circumstances.
Similarly, conversion to string (or for example, conversion within
client application) would then yield three possible different values:
'19:58:00 Europe/Amsterdam', '20:58:00 Europe/Amsterdam' or '21:58:00
Europe/Amsterdam' depending on the date of retrieval.
Three, not two? What additional transition do you have in Amsterdam?
With a single, constant date to derive TIME WITH TIME ZONE values for a
named zone, a consistent rule is established to be able to derive to
correct time within the zone (that is '20:58:00 Europe/Amsterdam').
Again, it's not correct, it's just consistent/invariant accross calendar.
If you don't want that, then don't save named zones in TIME WITH TIME
ZONE (hard to do, because of CURRENT_TIME), or always use TIMESTAMP WITH
TIME ZONE, so the rules are implicitly derived from the date included in
the timestamp.
Certainly. Hope you see why TIME WITH TIMEZONE is pointless.
Similar when storing to ZonedDateTime value
1. rebase the date to 2020-01-01 2. derive UTC time 3. store
So, for '2020-07-08 20:58:00 Europe/Amsterdam':
Step 1: change date to 2020-01-01: '2020-01-01 20:58:00
Europe/Amsterdam' Step 2: derive UTC time: '19:58:00 UTC' Step 3:
store '19:58:00 UTC' + id of Europe/Amsterdam
And you think that it's always the right value? I passed your example
trough dateutil library (Python 3.8):
>from dateutil import tz
>import datetime as dt
>ts = dt.datetime(2020,7,8,20,58,0,tzinfo=tz.gettz('Europe/Amsterdam'))
>print(ts)
2020-07-08 20:58:00+02:00
>print(ts.astimezone(tz.UTC))
2020-07-08 18:58:00+00:00
It seems that right UTC time should be 18:58:00 and not 19:58:00
No, because the date is rebased onto 2020-01-01, and on 2020-01-01, the
UTC time for 20:58:00 Europe/Amsterdam *is* 19:59:00 UTC. This ensures
that the time within the zone is preserved and can be consistently
reconstructed (see also above).
What was sort off reasonable for TIME WITH TZ where date is not present,
is definitely NOT acceptable for TIMESTAMP. The date is set there, so
how you can dare to rebase it? I even gave you example from widely used
library (could bring you more if one is not enough) that returns
different results. You can certainly figure out yourself what disaster
will happen in real world if application and Firebird (drivers included)
will use different math and rules? And the worst is that such "anomaly"
happens just for some time zones.
It's also not true that without rebase it could not be correctly
reconstructed from UTC. What you do means that data stored may not came
back as the same. If you consider this as acceptable, then we have
certainly different metrics for acceptance of data storage. For me it's
a cornerstone, and a reason why it gives me headache that I can't store
named timezone to get it back on retrieval (i.e. 'Europe/Amsterdam' will
be stored and thus retrieved as CET or CEST) because such information is
not available at driver level (because it's not available in Python in
general). I need to figure out a way how developers can pass this
information to the driver when needed.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Mark,
I use iUtil
Dne 08. 07. 20 v 17:44 Mark Rotteveel napsal(a):
The thing is, TIME WITH TIME ZONE for named time zone should be
considered at 2020-01-01, so the relevant DST rule for that date is
in effect.
Says who? Why 2020-01-01 and not other date? Because Firebird uses it
does not make it right, it just make it consistent with Firebird. Also
mind that DTS is just one from possible time shifts for timezone.
Sure, this can cause weirdness (especially if you have to convert a
CURRENT_TIME named zone to an offset zone value), but it is
consistent.
"Weirdness" is just a fancy name for wrong results.
But you can make the necessary mapping in the driver when you need to
derive the zone id by defining a mapping from CEST -> CET -> id
65156.
I use new FB4 iUtil encode/decode methods to convert data from/to
buffer. These methods use string timezone names (or '+-HH:MM' offsets).
On the other end I have Python datetime.time or datetime.datetime
objects with tzinfo. For input parameters, I can't get the name or
utcoffset out of datetime.time tzinfo for some timezones. I could get it
only through some date, and if I just pick some like 2020-01-01, it will
just screw up some time values. For datetime.datetime I have no problems
getting the timezone name except that some names are not recognized by
Firebird. If I would create name mapping, it would only crew up these
values, so simple name mapping will not cut it (mind that 12:30 CET !=
12:30 CEST).
The main problem is that tzinfo I get on input as part of datetime/time
values does not necessarily use region for timezone name, and there is
no way at the driver level to guess it. For example for tzinfo created
for 'Europe/Prague' I get either 'CET' or 'CEST', and the same apply for
'Europe/Amsterdam' (but the DST switch date could differ between these
regions). I can use utcoffset instead timezone name (conditionally when
error is returned by iUtil function or unconditionally), but this will
lead to lost information (offset instead zone id in database). And if
done conditionally there is no way how to report such coercion back to
the application.
For Jaybird I have defined a mapping between Firebird time zone ids
and the Java supported zone ids (which are basically the IANA tzdb
zone names, so the mapping is - almost - 100%, with a few I had to
manually remap to an equivalent zone name).
https://dateutil.readthedocs.io/en/stable/tz.html
All this stuff is based on standard system data definitions and
routines in standard libraries. I don't make up Python datetime
objects with timezone from thin air nor I fabricate them myself. If
any Python programmer will use standard way to get datetime with
zoneinfo from local system and pass it to the driver for storage in
database, I must handle it as is. I can't do any translations
(especially not just for some cases) in the driver. Mind that 12:30
in CET and CEST are different times in UTC, and 12:30 in
'Europe/Prague' could be also different UTC depending on the date.
In current state of affairs it means that for Python app. developer
some timezones could be stored in the database and some doesn't. It
has to be user's responsibility to provide ones that could be
stored.
I think I'm missing something and not understanding exactly what
you're stuck on.
As I said, CET is a zone that has a DST rule, that means that - for
example - on 2020-01-01, 12:30 CET is 11:30 UTC, while at 2020-06-02,
12:30 CET (== 12:30 CEST) is 10:30 UTC.
CET is NOT a zone with DTS rule, CET (Central European Time) is 1 hour
ahead of Coordinated Universal Time (UTC). This time zone is in use
during standard time in: Europe, Africa. Some places observe daylight
saving time/summer time during the summer, and therefore use CEST
(Central European Summer Time) in the summer. So, timezones like
'Europe/Prague' HAVE DST rules where they switch between CET and CEST.
For example Algeria and Tunisia have CET the whole year as they don't
switch to CEST.
See https://www.timeanddate.com/time/zones/cet
Firebird 'fixes' some of that confusion by basing such conversions at
2020-01-01.
Which is basically wrong if it does.
Similar when storing to ZonedDateTime value
1. rebase the date to 2020-01-01 2. derive UTC time 3. store
So, for '2020-07-08 20:58:00 Europe/Amsterdam':
Step 1: change date to 2020-01-01: '2020-01-01 20:58:00
Europe/Amsterdam' Step 2: derive UTC time: '19:58:00 UTC' Step 3:
store '19:58:00 UTC' + id of Europe/Amsterdam
And you think that it's always the right value? I passed your example
trough dateutil library (Python 3.8):
>from dateutil import tz
>import datetime as dt
>ts = dt.datetime(2020,7,8,20,58,0,tzinfo=tz.gettz('Europe/Amsterdam'))
>print(ts)
2020-07-08 20:58:00+02:00
>print(ts.astimezone(tz.UTC))
2020-07-08 18:58:00+00:00
It seems that right UTC time should be 18:58:00 and not 19:58:00
For the record:
>ts
datetime.datetime(2020, 7, 8, 20, 58,
tzinfo=tzfile('/usr/s
Re: [Firebird-devel] Crazy about time/timestamp with timezone
Dne 08. 07. 20 v 15:32 Mark Rotteveel napsal(a): TIME WITH TIMEZONE is pointless. It sort off works for "naive" TZ that does not have things like summer time and other time shifts based on date. The pytz library does not even allow you to create time with such tz. The dateutil does, but the usability is near zero, because you can't get offset, tz name etc from it (so also the calculations are crewed). It is not clear to me what problem you are having here. The problem is how this is handled in Python standard library. It does define only abstract base class for timezone handling (https://docs.python.org/3.8/library/datetime.html#tzinfo-objects). There are two implementations: packages dateutil and pytz. The pytz does not support tzinfo for time objects at all, only for datetime (timestamp). dateutil supports time with tzinfo, but it's practical usability is limited to simple timezones with no timeshifts etc. I can't even handle some of them in driver as it's not possible to get timezone info like name or utcoffset without date part for these complex ones. Then use 2020-01-01 as the date, because that is the date that > Firebird itself uses for basing TIME WITH TIME ZONE derivation for > named zones. This was the first thing I did but then rejected the idea. It allows me to store the TIME WITH TIMEZONE for such cases at the price that the value is crewed for DST. I'd rather reject the value than store wrong one. TIMESTAMP WITH TIMEZONE is ok. B. Storing into database. If a certain zone doesn't exist, you need to provide a mapping to the appropriate zones you want to use. For example, CET *is* CEST. That is: CET has a summertime rule, so the name CET is equivalent to CEST on dates in summer time (CEST is just a dumb alias for CET during summertime). However, it is highly recommend to stop using those short form zone identifiers as they are ambiguous. It is better to use the long form identifiers like Europe/Prague. And where I should get such mapping? Create and maintain it myself as part of Firebird driver? This stuff is handled by dateutil Python library that gets the data from system (on POSIX from description files, on Windows from registry or API). For example on Linux (POSIX), the 'Europe/Prague' timezone actually maps to file /usr/share/zoneinfo/Europe/Prague that contains data about this timezone that dateutil parses and uses. In fact the 'Europe/Prague' name is not part of this data so dateutil don't know it and can't return it, and such timezone name is just used to find the file on filesystem when tzinfo object is created. I also can't force dateutil to return CET instead CEST as timezone name if the time falls to summer time. And dateutil follows specification in POSIX zoneinfo file to get the name. https://dateutil.readthedocs.io/en/stable/tz.html All this stuff is based on standard system data definitions and routines in standard libraries. I don't make up Python datetime objects with timezone from thin air nor I fabricate them myself. If any Python programmer will use standard way to get datetime with zoneinfo from local system and pass it to the driver for storage in database, I must handle it as is. I can't do any translations (especially not just for some cases) in the driver. Mind that 12:30 in CET and CEST are different times in UTC, and 12:30 in 'Europe/Prague' could be also different UTC depending on the date. In current state of affairs it means that for Python app. developer some timezones could be stored in the database and some doesn't. It has to be user's responsibility to provide ones that could be stored. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Crazy about time/timestamp with timezone
Hi all, I'm trying to implement support for FB 4 TIME/TIMESTAMP WITH TIMEZONE in new Python driver, and I'm constantly hitting a stone wall with it. The TZ support in standard datetime Python module is nice, smart and flexible, but builtin support does not supports complex TZ with time shifts, only simple offset ones (standard support for these is in PEP stage, and may appear in Python 3.10 or later). The complex ones are supported via two libraries: dateutil and pytz. The dateutil is the preferred one. A. Reading from database TIME WITH TIMEZONE is pointless. It sort off works for "naive" TZ that does not have things like summer time and other time shifts based on date. The pytz library does not even allow you to create time with such tz. The dateutil does, but the usability is near zero, because you can't get offset, tz name etc from it (so also the calculations are crewed). TIMESTAMP WITH TIMEZONE is ok. B. Storing into database. TIME WITH TIMEZONE is impossible to store as I can't convert it successfully with iUtil.encodeTimeTz() because I can't get the TZ name or utcoffset for timezones like CET/CEST out of time value to pass it to this function. Yes, it's that convoluted, because the tzinfo object wants to decide the return value according to DST (or other execptions) and it needs date for that. If it can't, it returns None. TIMESTAMP WITH TIMEZONE is also busted, as Firebird does not know CEST timezone, only CET, and I can't twist/cast/whatever the python library to return CET when it's summer time. I could circumvent that with utcoffset instead zone name, but that would mean lost information (store offset instead time zone ID). And Europe/Prague (= CET or CEST depending on DST) is probably just an example when things get busted in other TZs. So far it's impossible to add TZ support into Firebird driver for Python that would work for all TZ in all cases. The data types will be supported, but reliability and usability will depend on actual TZ used. As I can't see how these problems could be solved at Firebird side (except missing TZ names like CEST), this rant is just for your information as the state of TZ support in it will have impact on our QA capabilities. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Dne 18. 06. 20 v 14:27 Mark Rotteveel napsal(a): Depending on the context, other usable terms to replace master could be agency hive primary conductor captain schemer guide Oh dear! Master is a "title" linked to top authority and professionalism in specific area (context) - like Master of ... Arts etc, it's not necessarily linked to power, or God forbid the slavery. Equivalent word/term/title exists in all languages. Hence using such term in any context to refer to top authority in given area is simple, clear, and easily translated to other languages (which is the primary reason why it's so popular). And for slave: "Slave" was an unfortunate choice as it has only one "hard" meaning in english. For non-native english speakers, it's natural to translate "slave" to word equivalent to "subordinate" in their native language, hence they mostly don't see it offensive as native english speakers, and for many the "slave" word may be pronounced more easily than "subordinate" or other replacement. But this cleansing crusade has nothing to do with masters and slaves, neither with common good. It's just frustration of people weaponized and redirected to wrong target, as eradicating words from our vocabulary achieves nothing positive for our societies. It will only shift us toward '84 where Hate is Love, Peace is War etc. Slaves and slavery is deeply part of our lives, we are slaves of our habits, many work conditions are pure slavery, parents can enslave their children physically and emotionally etc. and eradicating the word will not change that. In fact, as human mind needs words and images to operate, loosing words can (over few generations) effectively cripple our capacity to think about affected topics, which in turn will limit our capacity to solve linked problems. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Sean, Dne 18. 06. 20 v 0:15 Leyne, Sean napsal(a): 18.06.2020 00:00, Leyne, Sean wrote: "they" is also accepted as a singular, although it seems ungrammatical. Ok, thanks. BTW, when you start your search-and-replace work, don't forget to find substitutions for "owner", "invalid", "dependency" and "creator". First and third offend ex-slaves, second - disabled people, last - religious ones. How does this type of BS comment help the discussion? It only shows that you don't care about what others think about you or the project! If you don't care about the terms, then you can simply be quiet, let the people who do care, discuss and work on the changes. You should understand that while certain terms may offend certain people, vigorous actions that are clear Overton Windows shifting the society toward one controlled by minority of One Truth Owners may offend certain people as well. If you would be raised in Europe (especially central or eastern) in last century (or another place ruled by One Truth Owners), you would not be so surprised. You should also understand that changing terms is not the issue on itself. The problem is *why* we should do it. If the reason is primarily to follow others to keep their acceptance and not get eventually punished or excommunicated, then as classic wrote: "something is rotten in the state of Denmark". So, if you want to change certain terms to more precise ones in sake of clarity, be my guest. But there shall be no place in open source for pushing agenda of particular group interests unrelated to product itself. Open source shall be for all without any discrimination over any topic (and "positive" discrimination is still discrimination). best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Adriano, Dne 17. 06. 20 v 18:52 Adriano dos Santos Fernandes napsal(a): You like or not, the market will do things and specifically about replication, the terms where being changed already and will advance. There is no dispute that terminology evolves and if there are terms that are more accurate than accustomed ones, it's better to use them for sake of clarity. That's for example the case of "replica" instead "slave" in replication context. But master/slave is still the best method to explain or refer to controller/controlled principle that is accurate in all languages and does not need a thousand words, and master is still best term to describe anything with top authority in any context. Exterminating terms from all contexts just because someone sees it as offensive due to incidental reference to something that is currently perceived as disturbing by someone is a slippery slope that ends in dystopia. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Sean, Dne 17. 06. 20 v 17:09 Leyne, Sean napsal(a): Time to perform a simple search and replace!?!! If the terms being discussed were "commie", "chink", "pollack", "spik" "n.gg.r" would they be any less problematic? More argument fallacies? C'mon! I'm sure you can do better. Would we be arguing that "we don't have time"? "we don't have time" was just polite formulation. So far you do not explained why is absolutely necessary to do such change, you just insist. Or is there any "else" in it? I hope not. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Dne 17. 06. 20 v 2:57 Leyne, Sean napsal(a): If much larger projects than ours can make these changes, I don't see why we shouldn't be doing the same. When I was a kid and came up with such classic "Bandwagon Fallacy", my mother asked me "If others would go and jump off the cliff, does it mean you should do the same?". Removing the "master/slave" terms from IT vocabulary will not magically liberate the HW and SW from being slaves (btw, when we extended the human rights to machines?), neither it will help to remove human slavery from our lives. Removing terms always only hides the problem under the surface so it can live long and prosper there undisturbed (which is probably the point of those who fuel this "movement" with money and media coverage). It also has well documented trajectory. It always starts with common good that justifies first small, then bigger and then total changes, and ends with pitchforks and bonfires for those who don't follow. As we already seen people "burned" out from their lives and jobs for any overstepping, and advanced to tore-down the statues phase, the change of words is just a prelude for burning books. Those who can't learn from history are doomed to repeat the lesson through direct experience. Howgh! Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Modern C++: constexpr
Dne 16. 06. 20 v 21:13 Leyne, Sean napsal(a): we may have black list instead white list like now. As always better is to have both black + white. Even better would be "Allow" or "Allowed" and "Deny" or "Denied" terminology. Sean P.S.The same applies to the terms "master/slave" which should be "Primary/Replica" or "Primary/Secondary" or "Source/Destination". Certainly! And when we'll be at that, we should also use strictly gender-neutral terms everywhere and replace the red color with rainbow in our logo! Hail to the correctness, take no prisoners! Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB 4, iUtil and new interface in general
Alex, Dne 15. 06. 20 v 16:20 Alex Peshkoff via Firebird-devel napsal(a): On 2020-06-11 19:56, Pavel Cisar wrote: Adriano, Dne 11. 06. 20 v 16:38 Adriano dos Santos Fernandes napsal(a): 2. Strange things with iUtil in FB 4. a) Why methods getDecFloat16, getDecFloat34 and getInt128 require iStatus parameter? I expected that these methods should be "safe" like iMaster.getUtilInterface() and thus should not require iStatus. Methods that appear in non first version of an interface should have the status parameter as even if never return an error, it may be missing on a previous interface, which is an error. More below. Hmm, guess that it would make sense to have mandatory iStatus as first parameter in each method (regardless it's use to report errors), in any method added after initial 3.0 release. So there is in fact an error in IDecFloat16/34 interfaces that should be fixed before final, as BCD methods does not have it. Pay attention - not "each method added after FB3", but "each method that appear in non first version of an interface". I.e. DecFloat16/34 interfaces are OK. I really don't understand the rationale behind these strange rules. What I see is pure inconsistency as there are methods that have iStatus although they don't need it for anything, and methods that doesn't have it because they don't need it for anything. Could anyone explain what splitting these by fact it's first version of an interface or upgraded one is good for? It should have really strong technical reason to have such confusing rule. For interface consumer, presence of iStatus was clear indication that method may fail, and absence that it never fails. It was true for FB 3.0. Now it's not true anymore and I'd like understand why. best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB 4, iUtil and new interface in general
Vlad, I don't want to bound it at all :) Quite the opposite, it would be nice if statement prepare would NOT require active transaction at all. It would allow full decoupling of prepare from execution context in connectivity layer. I know that engine needs it for some reason (metadata?), but guess that engine could use fully internal transaction for that. regards Pavel Dne 12. 06. 20 v 9:05 Vlad Khorsun napsal(a): 12.06.2020 9:52, Pavel Cisar wrote: 2. The statement prepare requires active transaction although it's not bound to one. The same as ISC API. And this is fully correct. Why do you want to bound prepared request to the preparing transaction ? Regards, Vlad 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] FB 4, iUtil and new interface in general
Hi, Dne 11. 06. 20 v 19:00 Dimitry Sibiryakov napsal(a): > 11.06.2020 18:56, Pavel Cisar wrote: >> It would be a little bit unfortunate if we will end with 50+ method >> iUtil interface in FB 6, thought. > >I hope that before that time someone come with "very new API" that > will be a little better designed so this "new API" will get status > "deprecated". Well, that's a harsh statement :) If you have objections, you should provide a list with reasons why it's bad. I can't judge the whole new API as I used only the client part, but what I used from it so far was ok. Certainly, there are things I miss, but those are mostly inherited from old API that were not fixed by new one. Namely: 1. There is no way how to get precision of NUMERIC/DECIMAL data items. One has to query system tables, which is not always possible. 2. The statement prepare requires active transaction although it's not bound to one. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB 4, iUtil and new interface in general
Adriano, Dne 11. 06. 20 v 16:38 Adriano dos Santos Fernandes napsal(a): 2. Strange things with iUtil in FB 4. a) Why methods getDecFloat16, getDecFloat34 and getInt128 require iStatus parameter? I expected that these methods should be "safe" like iMaster.getUtilInterface() and thus should not require iStatus. Methods that appear in non first version of an interface should have the status parameter as even if never return an error, it may be missing on a previous interface, which is an error. More below. Hmm, guess that it would make sense to have mandatory iStatus as first parameter in each method (regardless it's use to report errors), in any method added after initial 3.0 release. So there is in fact an error in IDecFloat16/34 interfaces that should be fixed before final, as BCD methods does not have it. b) Is it possible to extract time/timestamp related methods from iUtil out to separate iTimezone interface like it was done for defloat/i128 ? The iUtil is a "sink" interface prone to change, which over time would make it [a] "crowded" and [b] subject of version escalation. If we consider whole set of functions, including ones in stable versions, what is different here is the decfloat, not the date/time functions. And the non-tz version are in released version already. iUtil was "don't fit anywhere, so it goes here" mash-up interface at the beginning. It's unfortunate it's future was not better thought out, but we could live with the "few" methods we've got in it with initial version. However, the "Util" name means that method list will only grow (it would certainly not happen if it would be named iLegacy). Just in FB 4 it would grow by 16 methods (to 29 in total) if it would follow the flat approach. Thankfully decfloat/i128 have their own interfaces that could grow *independently* from iUtil. It would be nice if we would have the same for datetime. Pity that it was not done initially with 4 decode/encode date/time functions, as it would become handy when timezone functions were added. Anyway, it would be nice if FB 4 will grow iUtil only by 4 new methods instead 9 as it is now, by moving tz-related ones in separate interface as well (and maybe *duplicating* the 4 ones from iUtil as well for convenience? or the without-tz type will be deprecated eventually?). It would be a little bit unfortunate if we will end with 50+ method iUtil interface in FB 6, thought. You may think that huge interfaces does not matter, and you will be certainly right that there is no real *technical* disadvantage. But they are really inconvenient for developers to use, i.e. to memorize and navigate the documentation and code completion, especially if they are "mash-up" ones like iUtil. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] FB 4, iUtil and new interface in general
Hi, The Firebird 4 is the first version that has "evolved" interfaces. This bring to table some important questions... 1. What is the official policy for evolution of interfaces? Will their version change every time they change, even if the change replaces "development" version like beta etc. ? I noticed that iUtil interface in FB 4 beta 2 has version 4, where version in FB 3.0.5 is (base) version 2. Where is the version 3? It gets "lost in updates" over development of FB 4 (3.0->4.0 alpha). This creates "mysterious" gap in versions between stable releases that we should IMHO avoid. On the other hand there is a precedent when interface was changed in backward incompatible way during development (and without version change). I'm ok with this as long as such changes would be properly announced in firebird-devel. So, I really wonder what is the official policy one can rely upon? If there is one, I missed the lesson when it was given. In case there is not one set in stone, I'd like propose next for "development" versions: If completely new interface is introduced, or interface that was part of stable release is changed, it will follow standard rules for versioning. This version will be "stable" over whole development cycle (i.e. it will be the final version for stable release), despite latter changes to it. This is supposed to be "dev" interface version and subject of change anyway, so there should be no trouble for its "users" if all changes to it will be properly documented at well known place and changes announced in firebird-devel. 2. Strange things with iUtil in FB 4. a) Why methods getDecFloat16, getDecFloat34 and getInt128 require iStatus parameter? I expected that these methods should be "safe" like iMaster.getUtilInterface() and thus should not require iStatus. b) Is it possible to extract time/timestamp related methods from iUtil out to separate iTimezone interface like it was done for defloat/i128 ? The iUtil is a "sink" interface prone to change, which over time would make it [a] "crowded" and [b] subject of version escalation. 3. Interface definitions in IDL file and inconsistent way for "versioning". a) The version is derived from number of base interfaces (inheritance chain). This is completely fine approach that makes sense. In generated files it uses inheritance to construct the interface. b) It uses "version:" tag inside interface definition to mark interface extensions. In generated file it has the same name and inheritance chain but different version and number of methods. And this is IMHO not fine. I can understand that method [b] allows stable "leaf" interface name and keep the inheritance chain minimal over time, but it has dire consequences as the interface becomes opaque. Imagine that you have an application that can work with different versions of Firebird, that may use different interface versions. You have to use the API file for most recent one, but when connected to older versions, you have to use just the "safe" part of returned interface. Sure you have to inspect the VERSION stored with interface, but then what? How you can tell from opaque interface which methods are safe for which version? You can't, you have to know beforehand from documentation, and any mistake is fatal at RUN TIME. This problem will build up with each FB release with new interfaces. And this lead us to part 4. 4. Status of cloop-generated interface files for C++ and Pascal. If new interface-based API is the way to go now, I suppose that these files are the official standard base for end users to access the new API from these languages, right? So their quality really matters (cloop bugs aside). I couldn't judge the C++ version, but I still understand Pascal a little, and it's clear that generated code is strictly paired with Firebird version for which is generated (due to their definition mentioned in point 3). If it will be used to access older FB version that returns older version of the interface (legal requirement), then safe use of the interface is completely up on developer. I.e. if it will call a method that is not in older version, it will crash and burn the application (in best case) without proper error handling, as the generated code doesn't handle this problem at all and lets the code crash and burn. From consumer's POV, this is IMHO not acceptable, so they would need either a better version or "real" interface library provided by someone else that solves this problem (it should at least raise an exception on illegal use). This is not a problem for languages like Python, Java and .NET that don't use these files at all, but C++ & Pascal are still important languages and we should offer some better solution. At least it should be discussed with those who use them (for example MWA Software, developer of ibx4lazarus?). A side note about interfaces and versioning in new Python driver for inspiration... It provid
Re: [Firebird-devel] Bug in cloop
Vlad, As these files are generated and should be used as is, you can safely use variant a) best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Bug in cloop
Hi, The Firebird.pas file generated by cloop contained wrong interface VERSIONs. While this issue was fixed in interface definitions (by Alex if I'm not mistaken), interface implementations still contains obviously wrong version numbers. Example from Firebird 4 Beta 2 Firebird.pas file: IXpbBuilderImpl_vTable := XpbBuilderVTable.create; IXpbBuilderImpl_vTable.version := 21; IXpbBuilderImpl_vTable.dispose := @IXpbBuilderImpl_disposeDispatcher; regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New API and scrollable cursors
Dne 27. 04. 20 v 18:09 Dmitry Yemanov napsal(a): 27.04.2020 17:34, Pavel Cisar wrote: The remote protocol support was simply forgotten because nobody asked for that for years. Mea culpa, I was too busy with the replication stuff. Obviously, not so many people use the new API... and even less people use new features introduced there. Well, users would use new API if connectivity package they use would use it. AFAIK only IBX2 provided new API layer as an option till now. Obviously Firebird & FreePascal/Delphi developers did not bother to change from old to new layer, did not use v3 or scroll in it, or used scrollable cursors in embedded-only applications. Unfortunately, Python is not a language of choice for embedded - it's mostly server development. One from main points I started to work on new driver was to help transition from old to new API, and to allow our QA to work with features available only trough it. I don't know if it's possible to provide such feature (even with embedded-only) in wire-protocol-based connectivity packages like JayBird or .NET Provider, but I guess if it would be doable, their maintainers would eventually implement it. Ok, shit happens, so what we will do now? Leave it to Firebird 5 that is who knows how many years in future, or would we try to provide it sooner? Personally, I think that remote scrollable cursors are just an improvement that could be introduced in any version, including maintenance ones, and are worth to be provided anytime sooner than in v5.0. regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New API and scrollable cursors
Dne 27. 04. 20 v 15:31 Dmitry Sibiryakov napsal(a): 27.04.2020 15:23, Pavel Cisar wrote: Or is the impression that this feature is not actually implemented really true? Yes it is true though should work in embedded mode. Well, I can confirm that IT WORKS *ONLY* in embedded mode. Could someone points me to any piece of documentation, Jira entry or even public e-mail that reveals such constraint to mere mortals using Firebird engine? Because I feel like a complete idiot now, and I want to know if it's because I can't read or because I'm too trusting (I can't find such constraint in FB 3.0.0-3.0.5 Release Notes or any piece of documentation in FB 3 distribution). Also, Alex confirmed that this is still not implemented in FB v4 trunk. Because I'm probably not the only one disappointed by this discovery, I really can't wait to hear an explanation and future prospects. best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] New API and scrollable cursors
Hi all, I have problem with scrollable cursor. With simple statement like "select * from country" (employee.fdb) and flag IStatement::CURSOR_TYPE_SCROLLABLE passed to IStatement.open_cursor(), any call to fetch[First|Prior|Last|Absolute|Relative] and is_bof() fails with error "feature is not supported". This error is internally registered as "wish_list", and digging in sources revealed that implementation of all these methods in /src/remote/client/interface.cpp unconditionally raise such exception. I'm really puzzled what is going on here. Did I do something wrong and there are some additional requirements for DSQL scrollable cursors other than scrollable flag? Or is the impression that this feature is not actually implemented really true? BTW, I work with FB 3.0.4 from OpenSuSE Tumbleweed best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB 3 & 4, new API and the ARRAY type
Adriano, Dne 22. 04. 20 v 14:02 Adriano dos Santos Fernandes napsal(a): It's perfectly possible to call fb_get_database_handle and fb_get_transaction_handle to go from new API to legacy API. Wonderful! But it's a shame that these functions and their existence is kept as well hidden secret, because they are NOT documented anywhere. Also, the Firebird.pas file does not import them at all (neither it provides Helper class/interface like Interface.h does for C/C++ developers, but one can live without this particular one). PLEASE, could this be fixed in 3.0.6/4.0 Documentation + Release Notes? BTW, the new API is really poorly documented, especially from the old->new API porting perspective. The examples + Using_OO_API.html are all nice, but they cover only basic aspects of new API usage and many not so frequently needed or typical are left untouched. Thankfully this really saved the day, and the new Python driver now has support for ARRAY type, although as crude hack. best regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB 3 & 4, new API and the ARRAY type
Dne 22. 04. 20 v 13:57 Jiří Činčura napsal(a): Although I don't disagree with what you said Pavel, I would support deprecation of arrays in FB4 (in fact I would support removal of arrays in FB4 and late-to-the-party deprecation in FB3, but that ship has probably sailed). I wouldn't bother closing the gap. Deprecation should be announced at least one version in advance (which is the proper routine everyone is used to). Because feature set for FB4 was defined & announced long time ago, and we are close to final release this year, I think it's too late to announce removal of ARRAYs from FB4 now. Although it would likely do no harm, it would be a bad signal to the public to be so much "unpredictable". Don't want to be in the same bandwagon with Microsoft. I have no problem with removal from FB 5. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] FB 3 & 4, new API and the ARRAY type
Hi all, I'm writing new Python driver built using new FB3 API (mainly to get support for new features not available through old API). I was surprised that ARRAY type support in new API is incomplete and thus it's not possible to handle this data type in drivers/applications. Specifically, the API provides getSlice & putSlice methods on IAttachment, but there isn't any equivalent for very important isc_array_lookup_bounds function (isc_array_lookup_desc and isc_array_set_desc are also missing, but they are not important for driver developers). Alex explained to me, that array support is not functional in new API, because core developers are considering to deprecate & remove ARRAY type support from future Firebird versions. And because the final decision was not made yet, the arrays support in new API get stuck in incomplete state. Personally, I have no problem with deprecation of the ARRAY type, as this type is mostly not used (if at all) by Firebird users. Also, I understand the reasoning for missing methods that would pollute the interfaces with methods that would become eventually obsolete. However, I'm really stunned how this issue was handled. While it's ok to provide only new API for new features (like scrollable cursors), the NEW API SHOULD support all old Firebird features present in given version and available through old API. And ARRAY type is such a feature. Although it's probably not used much by Firebird users, it's still used in example EMPLOYEE database that's used a lot in books, articles etc., and support for it is available to end users via some drivers (like FDB Python driver) for many years. So it's definitely POSSIBLE, that users will run into situations when lack of ARRAY support will be at least awkward (missing output), if not straight fatal. Argument that one could always use old API to access ARRAYs will not stand, because some new features are not available through it, and they could not be used together. Users should NOT be forced to choose between two API's with distinct features, at least one should be the superset (preferably the new one). Also, if ARRAY type should be ever removed from Firebird, it should be done via proper deprecation process (that also includes creation of new example database without it). Hence I consider the lack of (at least) isc_array_lookup_bounds equivalent in new API as a serious BUG, that should be fixed in Firebird 3 & 4. As driver developer I would really appreciate if it would be fixed for 3.0.6 due in June. While ARRAY support is the pressing matter here, there are other old API functions that does not have new API replacements (for example isc_blob_lookup_desc, and many others). I think that it's the good time to compare old and new API's, and create a document that will contain table listing the Old API functions with their New API counterparts, or explanation why it was decided to not provide such equivalent in new API. Such document should be first discussed here (so we could decide whether to fix more new API bugs asap), and then become a part of Firebird documentation set (as driver developer, I was really surprised that such document does not exists yet, as it's invaluable for porting from old to new API). best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6101) Conversion error on CASE using computed column
Conversion error on CASE using computed column -- Key: CORE-6101 URL: http://tracker.firebirdsql.org/browse/CORE-6101 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.4 Environment: Firebird-3.0.4.33054_0_x64 Windows 10 / Windows Server 2016 Reporter: Pavel Cisar Here is reproducible test: create table test_table_01 ( id int, get_temp_i computed by ((cast (64 as int))), fld2 int ); commit; insert into test_table_01 (id, fld2) values (1, 1); commit; select * from test_01; IDGET_TEMP_I FLD2 = 1641 select get_temp_i+1 from test_01; ADD = 65 select case get_temp_i when (get_temp_i = 1) then 1 else 2 end as case_result from test_table_01; CASE_RESULT Statement failed, SQLSTATE = 22018 conversion error from string "64" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6095) Extend trace record for COMMIT/ROLLBACK RETAINING to allow cjaing of transaction ids
Extend trace record for COMMIT/ROLLBACK RETAINING to allow cjaing of transaction ids Key: CORE-6095 URL: http://tracker.firebirdsql.org/browse/CORE-6095 Project: Firebird Core Issue Type: Improvement Affects Versions: 4.0 Beta 1, 3.0.4, 2.5.8 Reporter: Pavel Cisar After commit\rollback retaining transaction has a new number (but only when there are any changes to the database). This significantly complicates analysis of trace reports, as it's not easy to link events to the transaction context as transaction may change identity. It would be nice if trace entry for COMMIT/ROLLBACK RETAINING events would include both: original (or previous) transaction ID and new transaction ID, so trace log parsers could properly link events to transactions and retaining transactions into a chain. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6075) Trace configuration is not validated on session start
Trace configuration is not validated on session start - Key: CORE-6075 URL: http://tracker.firebirdsql.org/browse/CORE-6075 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.4 Reporter: Pavel Cisar Priority: Critical The trace configuration that is part of "start trace" API call is not parsed/validated on input. The configuration is parsed when other attachment will have something to trace and detect new trace session. At this point it's too late to report it correctly to the user. As this is not even logged in firebird.log, the final result is that all configuration errors are swallowed and trace produces no output. Making an error (typo, missing parenthesis or other) in configuration is easy. User can even mistakenly send (correct because previously tested and working) configuration in Firebird 2.5 format to the Firebird 3.0. As engine just happily starts the trace session that does not report anything wrong at any time and just produces nothing, it could easily lead to deep frustration in search for cause of the problem. The issue is that configuration is NOT validated on input (start trace session request). Engine should validate it and refuse to start the trace session with good error description where the problem is. This was verified on 3.0.4, but almost certainly affects all versions since 2.5 up to 4.0 beta 1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6074) Trace configuration sensitive to format
Trace configuration sensitive to format
---
Key: CORE-6074
URL: http://tracker.firebirdsql.org/browse/CORE-6074
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 3.0.4
Reporter: Pavel Cisar
Priority: Minor
This configuration is considered as wrong (silently does nothing):
database {
enabled = true
log_connections = true
}
while this one works fine:
database
{
enabled = true
log_connections = true
}
It's possible that configuration parser is sensitive to other "cosmetic"
divergences from canonical format.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Replication: declarative control
Hi, Dne 21. 02. 19 v 11:15 Dimitry Sibiryakov napsal(a): 21.02.2019 10:46, Pavel Cisar wrote: It's tempting, but I see potential for problems. If we would allow multiple sets & filters at master node, there is no need to have them at replica. And if replica would have different definitions than master, then it's not possible to replace master with replica in recovery scenario. Yes, if you limit usage of replica to standby/backup. But imagine kind of sharding when some tables are replicated in one database and others - to different one. It's not about the use case (sharding etc.) but about distribution of filters. We could have them either at master or at replica. If they would be at master, there is IMHO no much point to have them also at replica. Having master sets copied over to replica would allow easy standby solutions that could be harder to have if these would not be the same at both sides. Supporting filters at replica is IMHO only interim solution for sharding while multiple sets and filters are not supported at master. So I'd rather have all such multiple sets and filters at master (copied over to replicas) where they could be more easily managed than having different ones scattered all around. That way we could have both, sharding and standby in one shot and much trouble. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Replication: declarative control
Hi, Generally, I like the DDL approach more than using the configuration file. Additional benefit to ones listed is possibility to create various front-ends for replication configuration / integration of such functionality into existing Firebird management tools. Comments to specific question inline... Dne 21. 02. 19 v 9:14 Dmitry Yemanov napsal(a): One thing I'm worried about is whether it's enough to have a single global replication set or maybe it's useful to have many independent replication sets. How they can be used, for example: It would be nice to has such feature in future. 1) Two slightly different global replications sets are defined, only one of them is active at a time, but we can switch between them (e.g. via enable/disable commands) Hmm, can see an use case for it that would solve some problem and not cause trouble at the same time. I sense a great potential for users to shoot themselves to foot. 2) Different tables (separated by some rule) are included into different replication sets which are all active together, their intersection is used by the CDC publisher. This may be useful if these replication sets has some declarative customizations (see below). This would be certainly valuable. 3) Different replication sets are declared as intended for different CDC plugins. This implies that multiple CDC plugins may be configured independently. In this cases the CDC publisher checks the source (table) against the target (plugin) before sending the changes. This is certainly interesting. I can imagine a business case for a CDC plugin that does data stream processing instead persistence to some kind of replica. Second, IMHO declaring tables as "publishable" via CREATE|ALTER TABLE is too restrictive. I'd rather manage the replication set using some global commands, be it ALTER DATABASE or something different, allowing to include/exclude all tables at once, or comma-separated list of tables, or maybe tables by mask (regexp?). Of course, both SQL solutions (database level and table level) may co-exist. Agreed. However, would be database and table level definitions independent, or would we translate database level to batch of table ones? First would allow independent revocation but would complicate processing. Finally, if we consider the replication set being a filter, it may be also useful to limit the published change set to some particular operations (INSERT|UPDATE|DELETE) or even some particular rows (WHERE filter). I doubt this is useful for replication per se, but this may allow something similar to "change views" in InterBase, currently with a CDC plugin acting as a client, but perhaps it could be extended later to interact with the real client application. This would be certainly interesting. It would allow data sharding and all sorts of various interesting "utilizations" of replication plumbing for other things than just replication itself. And one partially related question from another angle: does it make sense to implement also replica-side declarative filtering? I mean the case where changes for all tables are journaled but for some reason only some tables should be applied to replica - e.g. two independent replicas with different filters but replicated from the same master journal (to avoid double journaling). If this feature is desirable, then how should the master-side filter (replication set) co-exist with the replica-side filter? It's tempting, but I see potential for problems. If we would allow multiple sets & filters at master node, there is no need to have them at replica. And if replica would have different definitions than master, then it's not possible to replace master with replica in recovery scenario. It could be an interim solution for absence of multiple sets & filters on master, but it would be hard to deprecate them once we implement such master solution. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] What is the cause for isc_login_changed errror?
Sorry, can you explain better. I wonder what configuration caused an error. Wrong order of authentication methods for client and server, along with WireCrypt parameters. We would detect that earlier if some sneaky weasel would not play with the config behind our back. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] What is the cause for isc_login_changed errror?
Alex, problem solved, it was a configuration issue after all. Sorry for false alarm. regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] What is the cause for isc_login_changed errror?
Alex, > login name and for what plugins is it present in user's list. Could you please explain this sentence? What plugins and user's list do you mean here? regards Pavel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] What is the cause for isc_login_changed errror?
Hi all, could anyone explain me what may cause the isc_login_changed error in FB 3 for non-sysdba users? (login works ok for sysdba) It's raised in server.cpp: ServerAuth->accept() best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Introducing Firebird Butler
We are pleased to announce a significant extension of the Firebird project to a whole new area. Starting in February 2019, alongside the core (Fierbird database system) and database drivers, a completely new division called Firebird Butler is integrated into the project. The purpose of the Butler division is to develop and provide solutions to various Firebird-related challenges faced by Firebird administrators and application developers that, for practical reasons, are not addressed by the core Firebird distribution. The primary aim of Firebird Butler is to create a development platform and develop a set of basic solutions to manage Firebird installations of any size, structure and complexity. The emphasis is on large corporate installations but the scope and ambitions of the Firebird Butler project are much broader: we would like to initiate development of an entire open source ecosystem of projects and other products, including commercial ones, in various languages. Projects could encompass not just the planned new services, but alternative implementations of the standard services as well. Moreover, the Firebird Butler Development Platform should become a solid foundation for development of any applications that use Service Oriented Architecture and messaging. For a closer look at the project goals and strategies, please read the "Introduction to Firebird Butler" at https://firebird-butler.rtfd.io/en/latest/introduction.html Although the project is only in the early stages of development, we encourage you to take a close look at what we have and where we are going. The project is completely open, and we will welcome anyone, individuals or organizations, who is interested in the objectives and strategy of the project and wishes to participate in its development, in a common or entirely private capacity, or to become its sponsor. Firebird Butler also presents a great opportunity for developers with experience in Python, Java, FreePascal, Delphi, C# or other languages to get involved in Firebird project activities. The Firebird Project Team Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Performance - 2.5 vs 3.0 vs 4.0
Hi, I think that there is enough evidence (provided from various sources, incl. this comparison) that 2.5 is still "significantly" (i.e. not in range that should be ignored) faster than 3.0. If 4.0 is even worse than 3.0, it's another indicator that profiling is needed to identify the problem spots. Gabor, do you think that you can create profiling logs from your tests setups? best regards Pavel Cisar IBPhoenix Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] User-defined aggregate functions
Hi, Aggregate UDF's are nice, but I think it's a mistake to think about them only in classic COUNT(), AVG(), SUM() etc. context. Why we don't look at them in more general way? Aggregates loop over input set and produce single value. Right now we do UDF-like aggregates inside PSQL SP using FOR SELECT loops or CURSORs. Moving the cursor definition up from SP/Func body to the caller would not only extend the flexibility of this aggregating procedures, but would allows seamless integration into GROUP BY and other contexts suitable for aggregation tasks. If we would introduce new parameter type -> the cursor, it would be perfect fit for enhanced FOR loop that could accept the cursor variable instead literal SQL statement. No need for SUSPEND, the UDF execution would be self-contained and with single invocation within given context. The input parameter could be provided by engine (as part of group by or other processing) or other UDF (we can already create cursors in PSQL using DECLARE CURSOR, and if we would extend it to allow creation of unassigned cursor variable and the possibility to store the EXECUTE STATEMENT handle into such CURSOR variable, it could be even more powerful). That way it could be easily comprehended general feature with simple rules and methods of invocation that could be used in various contexts and for various purposes. Aggregates could produce various single-value outputs, for example frequency distributions using an array, percent represented by string (number of # in fixed count of chars, as literal string etc.), they could produce hashes, JSON packets, URI path names etc. best regards Pavel Cisar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5812) Extending varchar domain leaves old smaller size in PSQL BLR
Extending varchar domain leaves old smaller size in PSQL BLR
Key: CORE-5812
URL: http://tracker.firebirdsql.org/browse/CORE-5812
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.8
Environment: First detected on this env:
WI-V2.5.7.27050 Firebird 2.5 classic
windows 10
Reporter: Pavel Cisar
Consistently reproducible test case:
create domain dmn varchar(1);
commit;
create table tbl(fld dmn);
commit;
set term ^;
create procedure sp
returns (fld dmn)
as begin
for select case when 1=1 then fld else 'x' end from tbl into :fld
do begin
suspend;
end
end
^
set term ;^
commit;
alter domain dmn type varchar(2);
commit;
insert into tbl (fld) values ('12');
commit;
set term ^;
alter procedure sp
returns (fld dmn)
as begin
select fld from tbl into :fld; /* select field uses new domain type
varchar(2) */
suspend;
end
^
set term ;^
commit;
select * from sp; /*no exception*/
commit;
set term ^;
alter procedure sp
returns (fld dmn)
as begin
select case when 1=1 then fld else 'x' end from tbl into :fld; /* case when
fld still uses old domain type varchar(1) in BLR */
suspend;
end
^
set term ;^
commit;
select * from sp; /*string truncation*/
commit;
/*reconnect*/
select * from sp; /*still string truncation*/
commit;
set term ^;
alter procedure sp
returns (fld dmn)
as begin
select case when 1=1 then fld else 'x' end from tbl into :fld; /* after
reconnect 'case when fld' starts to use new domain type varchar(2) in BLR */
suspend;
end
^
set term ;^
commit;
select * from sp; /*no more exception*/
commit;
drop procedure sp;
drop table tbl;
drop domain dmn;
commit;
--- Initial comment from Vlad Khorsun:
The issue is related with metadata caching (it was obvious). There is no cache
of domains, but there is cache of relations and cached relations
(of course) have fields with data types. When domain definition changed,
relations in cache are not invalidated. Thus, SQL parser uses old data
type (not domain based, just raw data type) when handle procedure text. In
particular, it CAST result of CASE expression to the VARCHAR(1) data
type. You may see in generated BLR something like
...
blr_cast, blr_varying2, 0,0, 1,0,
blr_value_if,
...
Later, when engine executed query, it knows real data type for the relation
field (VARCHAR(2)) but should CAST it to the VARCHAR(1) - here it raised
"string right truncation" error.
So far i see no quick way to fix it, sorry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5731) 'type of column' error message improvements
'type of column' error message improvements --- Key: CORE-5731 URL: http://tracker.firebirdsql.org/browse/CORE-5731 Project: Firebird Core Issue Type: Improvement Affects Versions: 2.5.8, 3.0.2 Reporter: Pavel Cisar after misspelling table in 'type of column' declaration error message begins with 'column does not exists', thus developers start looking for problems in wrong place (columns), and it may take a while to spot real error (table), e.g.: set term ^ ; create or alter procedure test_err as declare variable var type of column tbl.fld; begin select fld from tbl into :var; end ^ set term ; ^ commit; /*column FLD does not exist in table/view TBL*/ would it be possible to improve error messages and make it work like in 'select' statements (table has priority over columns): select fld from tbl; /*-Table unknown -TBL*/ select fld from rdb$database; /*-Column unknown -FLD*/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5617) Limit for Event table size
Limit for Event table size -- Key: CORE-5617 URL: http://tracker.firebirdsql.org/browse/CORE-5617 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 2.5.8, 3.0.3, 4.0 Beta 1 Reporter: Pavel Cisar Event table can grow without limits. This may lead to crash or server may hang, especially when badly written application registers interest to events in uncontrolled way (quick loop etc.). Engine should prevent this situation by imposing a hard limit to event table size, preferably as configurable value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5406) Wrong comparison of value with control character
Wrong comparison of value with control character Key: CORE-5406 URL: http://tracker.firebirdsql.org/browse/CORE-5406 Project: Firebird Core Issue Type: Bug Affects Versions: 2.5.6 Reporter: Pavel Cisar When column contains trailing control character (#13) then result of comparison depends on the presence of index on this column. Script to reproduce: CREATE TABLE T ( PK integer primary key, C1 CHAR(10), C2 VARCHAR(10) ); INSERT INTO T (PK, C1, C2) VALUES (1,'C1#','C1#'); INSERT INTO T (PK, C1, C2) VALUES (2,'C2#','C2#'); INSERT INTO T (PK, C1, C2); VALUES (3,'C2#' || ascii_char(13), 'C2#' || ascii_char(13)); INSERT INTO T (PK, C1, C2) VALUES (4,'C1#' || ascii_char(13), 'C1#' || ascii_char(13)); commit; SELECT a.*,char_length(c1),char_length(c2) FROM T a; Result PK C1C2 CHAR_LENGTH CHAR_LENGTH == == = = 1 C1# C1# 103 2 C2# C2# 103 3 C2# C2# 104 4 C1# C1# 104 SELECT a.*,char_length(c1),char_length(c2) FROM T a WHERE C1 <= 'C1#'; PK C1C2 CHAR_LENGTH CHAR_LENGTH == == = = 1 C1# C1# 10 3 4 C1# C1# 10 4 SELECT a.*,char_length(c1),char_length(c2) FROM T a WHERE C2 <= 'C1#'; PK C1C2 CHAR_LENGTH CHAR_LENGTH == == = = 1 C1# C1# 10 3 4 C1# C1# 10 4 CREATE INDEX IDX_T1 ON T (C1); CREATE INDEX IDX_T2 ON T (C2); commit; SELECT a.*,char_length(c1),char_length(c2) FROM T a WHERE C1 <= 'C1#'; PK C1C2 CHAR_LENGTH CHAR_LENGTH == == = = 1 C1# C1# 10 3 SELECT a.*,char_length(c1),char_length(c2) FROM T a WHERE C2 <= 'C1#'; PK C1C2 CHAR_LENGTH CHAR_LENGTH == == = = 1 C1# C1# 10 3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5354) Incorrect line number is shown in call stack
Incorrect line number is shown in call stack Key: CORE-5354 URL: http://tracker.firebirdsql.org/browse/CORE-5354 Project: Firebird Core Issue Type: Bug Affects Versions: 2.5.6 Reporter: Pavel Cisar Sample code below demonstrates incorrect line number in call stack. Commenting out 'first 5' in another 'select' statement above (in the code block which is not even executed) fixes the line number shown in call stack. (removing works the same as commenting out) Some stored procedures are quite big and it would be really helpful to know correct line number in case of similar errors. set term ^; create or alter procedure tmp_sp returns (i integer ) as declare variable j integer; begin if (1=2) then begin for select first 5 RDB$TYPE from RDB$TYPES into :j /* not executed, comment out `first 5` to get correct line number in call stack */ do begin /* ... */ end end else if (1=1) then begin Select RDB$TYPE from RDB$TYPES into :j; /* line 13, multiple rows exception happens here */ /* ... */ suspend; end else if (2=3) then begin /* ... */ suspend; end end /* line 20, call stack shows this line when `first 5` is used above */ ^ set term ;^ commit; select * from tmp_sp; /* should raise multiple rows exception at line 13, not 20 */ /*multiple rows in singleton select -At procedure 'TMP_SP' line: 20, col: 1*/ drop procedure tmp_sp; commit; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: Timeouts
Hi, that's very neat idea. +1 best regards Pavel Cisar IBPhoenix Dne 18.8.2016 v 12:04 liviuslivius napsal(a): > If i can start general discussion.. > > do you really use such feature in real systems? > I saw this in MSSQL environment and what was advice of DBA when someone reach > timeout? > Increase timeout settings... > > Kiling statement or transaction is not good as a general solution > It must be customized for situations. > > I suppose better feature will be "timeout messaging" - something like > TRIGGER ON STATEMENT_TIMEOUT > TRIGGER ON TRANSACTION_TIMEOUT > > and inside it we have access to MON$ tables and we can cancel statement, > transaction if we need. > Inside we can check e.g. individual context variables which eovercome some > default settings. > We can post event and some admin client application can take some action > i suppose you can run into more samples > > > P.S. > What about statements executing query to external database by EXECUTE > STATEMENT? > > regards, > Karol Bieniaszewski > > > > > > -- > 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] How an RDB$ index can be rebuilt in 3.0 ?
Hi, An RDB$INDEX_* is typically an automatically created one for constraint. So you have to identify the constraint, drop it and then recreate it. best regards Pavel Cisar IBPhoenix Dne 18.5.2016 v 21:03 Pavel Zotov napsal(a): > This question arised while discussion of CORE-5242. Vlad recommended me to ask > this here: > === > SQL> select rdb$index_name from rdb$indices where > rdb$relation_name='RDB$DEPENDENCIES'; > > RDB$INDEX_NAME > === > RDB$INDEX_27 > RDB$INDEX_28 > > SQL> ALTER INDEX RDB$INDEX_27 ACTIVE; > Statement failed, SQLSTATE = 28000 > unsuccessful metadata update > -ALTER INDEX RDB$INDEX_27 failed > === > So, how can some RDB$-index be repaired in 3.0 if this annoyance will occur ? > > > > -- > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird Conference 2016
Hi, Yes, it's planned and we're working on it. So far we have a place and date: Prague, Barcelo hotel, 7th-8th October 2016. Stay tuned, the official announcement with all details should come later in May or early in June. best regards Pavel Cisar IBPhoenix Dne 6.5.2016 v 10:00 marius adrian popa napsal(a): > Hello , > > Do we know the location or date for Firebird Conference this year ? -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5201) Return result code 1 when restore fails on activating and creating deferred user index
Return result code 1 when restore fails on activating and creating deferred user index -- Key: CORE-5201 URL: http://tracker.firebirdsql.org/browse/CORE-5201 Project: Firebird Core Issue Type: New Feature Components: GBAK Reporter: Pavel Cisar When restore fails to activate (and recreate) deferred index (typically due to insufficient temporary disk space), gbak returns FAIL result code (1) only when failed index is related to referential constraint. Failed user index is reported only to stderr (log if captured) but gbak returns result code 0. When restore is managed by script(s), it's not possible to easily detect this situation, and it's possible that database could be used with inactive index in production. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Physical replication using NBACKUP
Hi, May I suggest to add isc_info_* code to query the backup GUID via isc_database_info()? Parsing gstat output for it is very awful. New nbackup switches and options should be also handled by services API. best regards Pavel Cisar IBPhoenix -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] GitHub
Dmitry, For qa we only need these projects: https://github.com/firebirdsql/qa-fbtest (qa tools) https://github.com/firebirdsql/qa-repository (formerly fbt-repository - this is repository with tests and other data used by qa tools) https://github.com/firebirdsql/oltp-emul "benchmark" is very old and probably outdated. I need to check it someday if it's worth to carry on and can stay in svn for now. "qmtest" is deprecated and should not be moved. best regards Pavel Dne 13.3.2016 v 21:16 Dmitry Yemanov napsal(a): > 13.03.2016 19:10, Egor Pugin wrote: >> >> As I understand 'qa' in svn is a directory, not a project. Github does >> not support hierarchical structure. In 'qa' dir there are some repos: >> 'benchmark', 'fbtest', 'fbt-repository' etc. >> So, you'll have: >> https://github.com/firebirdsql/firebird >> https://github.com/firebirdsql/benchmark(s) (fine) >> https://github.com/firebirdsql/fbtest (fine) >> https://github.com/firebirdsql/fbt-repository (bad, 'repository' is > > I think they need to share a common prefix: > > https://github.com/firebirdsql/firebird > https://github.com/firebirdsql/qa-fbtest > https://github.com/firebirdsql/qa-qmdb > etc > > or > > https://github.com/firebirdsql/firebird > https://github.com/firebirdsql/firebird-qa-fbtest > https://github.com/firebirdsql/firebird-qa-qmdb > etc > > As for benchmarks, maybe they deserve a "root namespace" repo: > > https://github.com/firebirdsql/benchmarks > > > Dmitry > > > -- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5078) "Invalid BLOB ID" error
"Invalid BLOB ID" error
---
Key: CORE-5078
URL: http://tracker.firebirdsql.org/browse/CORE-5078
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.5, 2.5.4, 2.5.3 Update 1, 2.5.3, 2.5.2
Reporter: Pavel Cisar
After we switched couple columns from big varchar to blob one customer
reported 'Invalid BLOB ID' error. Unfortunately we were not able to
notice any pattern to explain what could be causing it thus we were not
able to create test case from scratch. Luckily we were able to strip
client DB down to one simplified SP (and three tables) where it happens
every time for us on 64 bit classic firebird 2.5.5 on windows
(32 bit 2.5.2/3/4/5 fb works fine, 64 bit 2.5.2/3/4/5 on windows and
2.5.3 on linux also generates error here). DB backup file is attached,
executing 'select * from do_changeTxStatus;' causes the error. SP code
and results we get follow below. SP code is made by combining multiple other
SPs and triggers, and then stripped down as much as possible, so the
code may not make any sense, it's just to demonstrate the error
set term ^;
create or alter procedure do_changeTxStatus
returns (info varchar(20), UPDCNT INTEGER, trans integer, subs integer,
MsgType integer, notifyParams integer)
as
declare variable tmpmessage blob;
begin
updCnt=0;
for select trans, subs
from trans
order by trans -- or 'subs desc' generates error, 'trans desc' or 'subs' --
no error
into :trans, :subs
do begin
for select distinct MsgType --removing distinct eliminates error
from NotifyParams p
where sscTableKey = :Subs
into :MsgType
do begin
info='assigning blob';
suspend;
tmpmessage='1606=222=333'; -- eliminating temp variable
eliminates error
for select p.notifyParams
from NotifyParams p
where p.sscTableKey = :Subs
into :notifyParams
do begin
updCnt=updCnt+1;
info='inserting blob';
suspend;
insert into PendingSC (pendingSc, Priority, CommandBlob)
values (GEN_ID(GENID_PENDINGSC, 1), 500, :tmpMessage);
end
end
end
end
^
set term ;^
commit;
select * from do_changeTxStatus;
INFO UPDCNTTRANS SUBS MSGTYPE
NOTIFYPARAMS
assigning blob 0 1361557 1449 2525
inserting blob 1 1361557 1449 2525
265
assigning blob 1 1361558 7955 2525
265
inserting blob 2 1361558 7955 2525
829
assigning blob 2 1361563 6707 2525
829
inserting blob 3 1361563 6707 2525
597
assigning blob 3 1361564 1502 2524
597
inserting blob 4 1361564 1502 2524
277
inserting blob 5 1361564 1502 2524
278
inserting blob 6 1361564 1502 2524
279
inserting blob 7 1361564 1502 2524
1340
assigning blob 7 1361564 1502 2525
1340
inserting blob 8 1361564 1502 2525
277
inserting blob 9 1361564 1502 2525
278
inserting blob 10 1361564 1502 2525
279
inserting blob 11 1361564 1502 2525
1340
assigning blob 11 1361566 7021 2525
1340
inserting blob 12 1361566 7021 2525
630
assigning blob 12 1361569 6614 2525
630
inserting blob 13 1361569 6614 2525
586
assigning blob 13 1361570 8303 2525
586
inserting blob 14 1361570 8303 2525
1668
assigning blob 14 1361572 7917 2525
1668
inserting blob 15 1361572 7917 2525
811
assigning blob 15 1361573 7523 2525
811
inserting blob 16 1361573 7523 2525
1187
assigning blob
[Firebird-devel] Literals in CASE expression
Hi all,
We have an annoying little problem. The visible manifestation is that
literals in CASE expressions could be padded with spaces.
Here is simplified example:
set term ^;
create procedure tmp_sp(pParam integer)
returns (selectionIf varchar(40), selectionCase varchar(40))
as
declare variable color varchar(10);
begin
if (pParam=1) then color='red';
else if (pParam=2) then color='yellow';
selectionIf='You have selected '||:color||' bag';
color=case :pParam when 1 then 'red' when 2 then 'yellow' end;
selectionCase='You have selected '||:color||' bag';
suspend;
end
^
set term ;^
select * from tmp_sp(1);
SELECTIONIF SELECTIONCASE
===
You have selected red bag You have selected redbag
drop procedure tmp_sp;
commit;
---
Padding with spaces is not a bug! Spaces are there because string
literals are CHARs, NOT VARCHARs. This is required by SQL standard.
Relevant except from SQL standard:
5 Lexical elements
5.3
Syntax Rules
...
15) The declared type of a is fixed-length
character string. The length of a is the
number of s that it contains.
...
6 Scalar expressions
6.11
Syntax Rules
...
7) The declared type of a is determined by applying
Subclause 9.3, ‘‘Data types of results of aggregations’’, to the declared
types of all s in the .
9 Additional common rules
9.3 Data types of results of aggregations
Syntax Rules
...
3) Case:
a) If any of the data types in DTS is character string, then:
...
iii) Case:
1) If any of the data types in DTS is character large object string,
then the result data type is character large object string with
maximum length in characters equal to the maximum of the lengths in
characters and maximum lengths in characters of the data types in DTS.
2) If any of the data types in DTS is variable-length character string,
then the result data type is variable-length character string with
maximum length in characters equal to the maximum of the lengths in
characters and maximum lengths in characters of the data types in DTS.
3) Otherwise, the result data type is fixed-length character string with
length in characters equal to the maximum of the lengths in characters
of the data types in DTS.
To sum it up, standard dictates that literals are CHARs, aggregated
values has length of longest one and because CHARs are padded with
spaces to declared length, we have such stupid output in CASE. Sure, it
could be easily "fixed" with CAST or TRIM, but it's extremely annoying
to do so. And if there is any real world case when CHAR is the right
type for literals and VARCHAR the wrong one, I can't see it and would be
glad to be enlightened by someone else.
You may ask why I'm raising this issue here when Firebird's policy is to
follow SQL standard whenever possible (even with stupid requirements),
so annoying or not, we have to live with it. BUT... other databases are
not so strict here, break the stupid standard requirement and use
VARCHAR instead CHAR, for example:
MS SQLServer 2012:
SELECT 'a'+case 1 when 1 then '1 ' when 2 then '222' end+'b'
FROM [SCM].[dbo].[SERVERID]
a1 b
(1 row(s) affected)
mySQL 5.6:
select concat('a', case 1 when 1 then '1 ' when 2 then '222'
end, 'b') from tmp;
| concat('a', case 1 when 1 then '1 ' when 2 then '222' end, 'b') |
|---|
| a1 b |
oracle (not sure which version, provided by sqlZoo.net):
SELECT 'a'||case 1 when 1 then '1 ' when 2 then '222' end||'b'
FROM world
'A'||CASE1WHE..
a1 b
...
PostgreSQL (not sure which version, provided by sqlZoo.net):
select concat('a', case 1 when 1 then '1 ' when 2 then '222'
end, 'b') from world
concat
a1 b
...
db2 (not sure which version, provided by sqlZoo.net):
SELECT 'a'||case 1 when 1 then '1 ' when 2 then '222' end||'b'
FROM world
1
a1 b
...
So Firebird stands out from the flock here with:
SELECT 'a'||case 1 when 1 then '1 ' when 2 then '222' end||'b'
FROM rdb$database;
CONCATENATION
=
a1 b
---
So Firebird behavior is even more annoying when you (have to or was used
to) work with other databases.
My question is: Could we sacrifice the standard compliance a little bit
by using VARCHAR instead CHAR (length rules remain the same!) as others
do? Because following the standard here really doesn't work in our favor
in this particular case.
My personal vote is for relaxing the rules and use VARCHAR. What is your
opinion?
best regards
Pavel Cisar
IBPhoenix
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4691) Wrong database location resolution when DatabaseAccess restriced to specified directories
Wrong database location resolution when DatabaseAccess restriced to specified directories - Key: CORE-4691 URL: http://tracker.firebirdsql.org/browse/CORE-4691 Project: Firebird Core Issue Type: Bug Components: GSTAT Affects Versions: 2.5.3 Update 1, 2.5.3, 2.5.2 Update 1, 2.5.2, 2.5.1, 2.5.0 Reporter: Pavel Cisar gstat (without user/pwd parameters, just -h header scan) doesn't open database in CWD when db filename is specified without full path and filename is located in directory listed in DatabaseAccess spec. Example: srv:/ssd # /opt/firebird/bin/gstat -h mydb.fdb Database "/sata/mydb.fdb" when specifying path it opens correct file: srv:/ssd # /opt/firebird/bin/gstat -h /ssd/mydb.fdb Database "/ssd/mydb.fdb" DatabaseAccess = Restrict /data/db;/data/db2;/sata;/ssd;/ramfs gstat tries to resolve the given filename via aliases.conf in order to support aliases. In 2.5 it was intended that ResolveDatabaseAlias() routine was modified to transform relative paths via DatabaseAccess. But it should have been done only for the engine, not for utilities that also use ResolveDatabaseAlias() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4642) Can't connect to database without path from CWD when DatabaseAccess is restricted
Can't connect to database without path from CWD when DatabaseAccess is restricted - Key: CORE-4642 URL: http://tracker.firebirdsql.org/browse/CORE-4642 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3 Update 1, 2.5.3 Environment: Firebird Classic, local/embedded access on Linux Reporter: Pavel Cisar Priority: Minor When DatabaseAccess configuration option is set to Restrict, an attempt to connect to database file located in CWD without path fails if database is not located in restricted directory-root but in subdirectory firebird.conf DatabaseAccess = Restrict /home/data command: /home/data/db # /opt/firebird/bin/isql database.fdb -user sysdba -pas masterkey Statement failed, SQLSTATE = 08001 I/O error during "open" operation for file "database.fdb" -Error while trying to open file -No such file or directory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Fb3 daily build and test broken
Hi, I'd gladly look into it, but I can't test it. It works for 2.5.3 and I can't install latest 3.0 as there is no 64-bit Linux build, and Alpha 2 doesn't work on my openSUSE 13.1 (problem with icu). best regards Pavel Dne 24.11.2014 v 10:13 Philippe Makowski napsal(a): > The bug is in Python fdb driver > > If I launch test suite with fdb at svn rev 59844 > then, no crash > > Pavel your latest changes in fdb lead to regression, FDB v1.4.2 (actual > trunk) crash during Firebird test suite > > > > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4578) INPUT file not properly closed
INPUT file not properly closed -- Key: CORE-4578 URL: http://tracker.firebirdsql.org/browse/CORE-4578 Project: Firebird Core Issue Type: Bug Components: ISQL Affects Versions: 2.5.3 Environment: Windows XP Reporter: Pavel Cisar Attachments: test_case.zip This is regression from previous versions. File used as input for isql commands can't be deleted before isql session ends. Users executing isql scripts that use temporary command input files (typically created as isql output stored in file) can't delete those in the same script. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] FB 3.0 New API missing in alpha1?
Hi all, I can't find Provider.h in Alpha1 Linux package. It's intentional (new API not ready for testing) or not (packaging error)? best regards Pavel Cisar IBPhoenix -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 Alpha 1 issues
Dne 3.7.2013 20:30, Alex Peshkov napsal(a): > 03.07.2013 19:04, Pavel Cisar пишет: >> Hi, >> >> Well, I have discovered that 3.0 Linux installation script doesn't >> install FB as server > > ??? > May be default connection is embedded? Yes, it's embedded. I'm ok with it if i would know, but there is no information about it in release notes or in any doc. file included. It was also disappointing that init.d control script was not installed, and if it's even part of installation, I didn't found it. But what the hell, it' alpha :) Pavel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 Alpha 1 issues
Hi,
Well, I have discovered that 3.0 Linux installation script doesn't
install FB as server, so without host specification it works as embedded
(that was new for me), so all reported issues were for embedded (Linux
64-bit). Now I have report also for server. Note, that all reported
issues are regressions.
Dne 1.7.2013 15:33, Dmitry Yemanov napsal(a):
> 01.07.2013 17:14, Pavel Cisar wrote:
>>
>> 1. cursor.rowcount (isc_dsql_sql_info with isc_info_sql_records) returns
>> 1 instead expected 6
>>
>> cur.execute('select * from project')
>> self.assertEqual(cur.rowcount,0)
>> cur.fetchone()
>> self.assertEqual(cur.rowcount,6) <--
>
> Correct for embedded connections (no record prefetch), incorrect for
> remote connections (including localhost).
Confirmed, test adapted.
>> 2. MON$ATTACHMENTS. Next columns are NULL: MON$REMOTE_PROTOCOL,
>> mon$remote_address, mon$remote_pid, mon$remote_process.
>
> Correct for embedded connections (no network layer involved), incorrect
> for remote connections (including localhost).
Confirmed, test adapted.
>> 3. Unexpected RDB$VALID_BLR = True on stored procedure in database
>> restored by v3.0
>
> Why is it unexpected?
Sorry, my bad. True is of course correct. I was misguided because FB <
3.0 returns NONE.
>> 4. Can't get list of users via services API. Returns:
>>
>> Unable to perform the requested Service API action:
>> - SQLCODE: -901
>> - unrecognized service parameter block
>> - All services except for getting server log require switches'
>>
>> -901
>> 335544562
>>
>> BTW, Flamerobin fails with the same error on attempt to get list of
>> users from server.
Also fails with localhost. I suppose it's a bug.
>> 5. Call to isc_service_query with isc_info_svc_running raises error:
>>
>> Services/isc_service_query:
>> - SQLCODE: -901
>> - invalid service handle'
>>
>> -901
>> 335544559
>>
>> Service handle is valid. This call fails ONLY before some actions are
>> requested (via isc_service_start),
>> for example isc_action_svc_get_ib_log. Once any service is started,
>> isc_service_query starts to work properly.
>
> Sounds like a bug.
Indeed. Result from localhost could give you a hint, as it fails with
other error:
Services/isc_service_query:
- SQLCODE: -902
- Your user name and password are not defined. Ask your database
administrator to set up a Firebird login.
- No auth of running service
6. Working with limbo transactions (real ones, test using DT carefully
crafted, works in FB < 3.0) causes problems, needs further investigations.
Asking for limbo id succeeds for first database, but fails when asking
for second ones.
ids2 = svc.get_limbo_transaction_ids(self.db2) ->
Exception: OperationalError: ('Unable to perform the requested Service
API action:\n- SQLCODE: -902\n- Your user name and password are not
defined. Ask your database administrator to set up a Firebird login.\n-
Client error - database name does not match', -902, 335544472)
7. With localhost (embedded is fine), tests test_restore and
test_nrestore fail with:
Unable to perform the requested Service API action:
- SQLCODE: -902
- Your user name and password are not defined. Ask your database
administrator to set up a Firebird login.
- Client error - database name does not match
-902
335544472
best regards
Pavel Cisar
IBPhoenix
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Firebird 3.0 Alpha 1 issues
Hi,
Next issues were discovered via FDB test suite. Tested on 64-bit Linux,
default configuration (i.e. vanila install from tar.gz).
1. cursor.rowcount (isc_dsql_sql_info with isc_info_sql_records) returns
1 instead expected 6
cur.execute('select * from project')
self.assertEqual(cur.rowcount,0)
cur.fetchone()
self.assertEqual(cur.rowcount,6) <--
2. MON$ATTACHMENTS. Next columns are NULL: MON$REMOTE_PROTOCOL,
mon$remote_address, mon$remote_pid, mon$remote_process.
3. Unexpected RDB$VALID_BLR = True on stored procedure in database
restored by v3.0
4. Can't get list of users via services API. Returns:
Unable to perform the requested Service API action:
- SQLCODE: -901
- unrecognized service parameter block
- All services except for getting server log require switches'
-901
335544562
BTW, Flamerobin fails with the same error on attempt to get list of
users from server.
5. Call to isc_service_query with isc_info_svc_running raises error:
Services/isc_service_query:
- SQLCODE: -901
- invalid service handle'
-901
335544559
Service handle is valid. This call fails ONLY before some actions are
requested (via isc_service_start),
for example isc_action_svc_get_ib_log. Once any service is started,
isc_service_query starts to work properly.
Other isc_service_query items except isc_info_svc_running work fine, for
example query for isc_info_svc_server_version.
best regards
Pavel Cisar
IBPhoenix
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RFC: human-readable DBKEY
Hi, Dne 5.4.2013 08:04, Dmitry Yemanov napsal(a): > All, > > I'd like to propose some ways to convert DBKEY into a human-readable > form but still be able to quickly (without a full table scan) access the > record via its human-readable DBKEY. > > Primarily, it could be used to report a unique id of the offending > record in error messages allowing users to easily locate that record. > But it could be used for other purposes as well. > > So far I can think of two solutions: > > 1) Add two symmetric built-in functions: DBKEY_TO_CHAR and > CHAR_TO_DBKEY. The former one would return the predefined hex-encoded > textual representation of the DBKEY while the latter one would perform > the opposite transformation. So one would need to SELECT > DBKEY_TO_CHAR(RDB$DB_KEY) ... (or just copy'n'paste from the error > message) and then SELECT ... WHERE RDB$DB_KEY = CHAR_TO_DBKEY(?). > > 2) Add pseudo-column RDB$RECORD_NUMBER which would return rpb_number as > BIGINT (can be easily converted from/to text). Modify the engine so that > search for RDB$RECORD_NUMBER would work similar to the searching for > RDB$DB_KEY i.e. use a fast positioned table access. > > Opinions? Any other suggestions? I like 1) more. regards Pavel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird new release is needed
Alex, Dne 15.3.2013 14:08, Alex Peshkoff napsal(a): > > Pavel, why do you think we need QA after with the single one-line patch? > IMO check for installability (avoid network errors) is enough. > The main reason for releasing that versions is avoiding QA and long > release notes cycle. (yes, we need new release notes but with singe line > change do not need a lot of versions after reviews in the lists). Depends on how strong the QA should be. In rigid QA terms, you can't be sure it's ok until you test it, period. Even if you will not change any source line, new build is new "beast" (as something may go wrong in build process, or packaging or whatever). Regardless your expectations, you can't be sure. That's the point of QA approval stamp - users can be sure (to certain degree set by QA process) that this particular binary is ok, nothing more and nothing less. So, if we'll test only packaging and installation, people could be sure that it could be unpacked and installed, nothing more and nothing less. I agree that all could expect with high level of certainty that it will be generally ok as the previous build, and this might be ok for 99.99% of users, but if I'd be admin of FB installation in bank for example, I'd not trust it as previous build, as it was not "fully" QA'ed. Anyway, I'm ok with "soft" QA on this one IF it would be announced as such. regards Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird new release is needed
Hi, Dne 15.3.2013 12:53, Dmitry Yemanov napsal(a): > All, > > I see only two choices good enough for considering: > > a) Release 2.1.5.18497 and 2.5.2.26540 (suffixed with "Security Update > 1"), don't mark it as a separate release but replace the binaries with > the new version (like we did for the "bad" builds in the past). > > The question here is whether we need to publish the fixed v2.0.7 as > well. It's discontinued but present on our website home page. > > b) Defer the security patch till 2.1.6 and 2.5.3 but try releasing them > earlier than scheduled originally. IMO, this is easier to do with v2.5.3 > which is currently scheduled for Q2 and already has enough bugfixes than > for v2.1.6 that is expected to appear in late summer and still counts > only 11 bugfixes. From QA perspective there is small difference between both. As we will have to run full QA on both versions at the same time (so expect it will take twice as much time as normally when we have only one at hand). However, B) means we will not run another round for 2.5.3 shortly after this one. If there are not enough fixes to roll out 2.1.6, then how about mixed scenario (2.5.3 + 2.1.5 with suffix)? regards Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Fwd: SourceForge Repo Clone Complete
Původní zpráva Předmět:SourceForge Repo Clone Complete Datum: Sun, 16 Dec 2012 12:20:34 + Od: SourceForge.net Přeposláno - Komu: nore...@in.sf.net Komu: nore...@in.sf.net Your cloned repository code in project firebird is now ready for use. Old repository url: http://firebird.svn.sourceforge.net/svnroot/firebird New repository checkout command: svn checkout --username=pcisar svn+ssh://pci...@svn.code.sf.net/p/firebird/code/trunk firebird-code You and any other developers should do a fresh checkout using the new repository location. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Upgrade of Firebird project to new Allura platform
Dne 16.12.2012 10:50, Alex Peshkoff napsal(a): > On 12/16/12 13:43, Alex Peshkoff wrote: >> On 12/16/12 12:53, Mark Rotteveel wrote: >>> On 15-12-2012 12:46, Pavel Cisar wrote: >>>> Mark, >>>> >>>> Core upgrade is already finished, now it migrates code repositories >>>> (don't know how long it will take as ours are huge). Project developers >>>> should get an automatic e-mail when it's done. I'll forward it here too >>>> for others. >>> Is there any indication of progress? Because it has already taken 22 >>> hours... That is a bit long in my book. >>> >> Appears a bit strange - but old repository still works for me. >> > Ahh - understood. It's RO now. And status is still importing... > Pavel, is not it time to ask SF for support? I understand that our repo > is big, but at least it's 2012 now, and servers are fast. I have created support ticket for that. Pavel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Upgrade of Firebird project to new Allura platform
Dne 15.12.2012 12:50, Mark Rotteveel napsal(a): > Yes, I just received an e-mail that the migration was done and that it > now started on the repositories. I guess that will take a while. > > That e-mail says "That means that you and any other developers should do > a fresh checkout using the new repository location when it is ready". > With Subversion you can switch (relocate) your repository to a new > location, any idea why they say you need a fresh checkout? Generic e-mail, SF supports multiple versioning systems where some doesn't support this feature. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Upgrade of Firebird project to new Allura platform
Mark, Core upgrade is already finished, now it migrates code repositories (don't know how long it will take as ours are huge). Project developers should get an automatic e-mail when it's done. I'll forward it here too for others. Pavel Dne 15.12.2012 12:30, Mark Rotteveel napsal(a): > > At what time do you start (or if you already started: finish)? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Upgrade of Firebird project to new Allura platform
Hi all, On (this) Saturday 15th we will upgrade the Firebird project on SourceForge to new SourceForge platform. The project facilities (notably source repositories) would be temporarily unavailable. There is nothing special about the upgrade, but URLs to our source code repositories will change. best regards Pavel Cisar -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 12:26, Alex Peshkoff napsal(a): > On 10/31/12 15:03, Pavel Cisar wrote: >> > > Let me answer. As a minimum - shared pages cache and i.e. better SMP > support. But only if you need both of them at the same time, individually they're provided by pre-3.0 versions. Anyway, this is just potential benefit, I was asking what this application *really* need that only 3.0 can provide in situation that it works "just fine" for last twelve years :) regards --Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 11:40, Dimitry Sibiryakov napsal(a): > 31.10.2012 11:36, Pavel Cisar wrote: >> So negative impact would be to very small fraction of FB users, while >> positive impact would affect the rest. > > Could you tell more about this "positive impact"?.. For example: 1. Cleaner code - less potential for bugs. 2. Resources spent on backward compatibility could be spent on something else. 3. New interfaces could be simpler without dialects (if they're not D3-only already). Less hassles with old APIs as dialect would be (optional) ignored. regards --Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 11:46, Lester Caine napsal(a): > Pavel Cisar wrote: >> b) If we will announce the removal of dialect 1 support now, users of >> dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to >> adapt their applications (for early adoption) and about 5-7 years as >> final deadline (when support of last FB version having dialect 1 would >> be discontinued by*project*). IMHO plenty of time. > > One would think so - but I'm still running systems first installed in the late > 90's ;) They work just fine still and the customers will not let me change > them. > The current schemas are still compatible with the data from the last century. But the important question here is whether you plan to switch these systems to run on FB 3.0 or not? If you plan to do that and they're actually "untouchable", what benefit you expect from the transition to FB 3.0? regards Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Hi, Well, if removing dialect 1 in FB 3.0 is NOT out of question, I'm strongly for its removal (not just deprecation) in 3.0. While some may object that it's: a) violation of our deprecation policy. b) not advance enough notification to give users time to adapt. I would like point out that: a) There is no "project manifest" or "development contract" at our website that would codify such deprecation policy. It's just convenient routine we decided to follow. So we're not bound to follow it to the letter, as there is no such letter and never was. b) If we will announce the removal of dialect 1 support now, users of dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to adapt their applications (for early adoption) and about 5-7 years as final deadline (when support of last FB version having dialect 1 would be discontinued by *project*). IMHO plenty of time. We should also take into account the impact factor of such move: a) It's mostly about pre-IB 6.0 applications that were not adapted to dialect 3 since then. How many such apps do you think it's still out there? Up to 0.01% ? b) All new applications since IB 6.0 / FB 1.0 are dialect 3 applications, with very very few exception (if there are any at all). So negative impact would be to very small fraction of FB users, while positive impact would affect the rest. Over all 12 years of FB development it became clear that *remaining* dialect 1 users simply can't switch at all (old legacy app, they certainly switch with new app. versions), so giving them another 2 years inserting deprecation version before removal will not help them in any significant way. So in my opinion it's ok to announce the removal of dialect 1 in 3.0 NOW, and do it. Especially when 3.0 is (and was) presented for long time as Firebird "reborn" version (new ODS, new API, new architecture etc.) and a potential deal-breaker for legacy stuff. best regards Pavel Cisar IBPhoenix Dne 31.10.2012 10:02, Dmitry Yemanov napsal(a): > > Sorry, I had intended to write: > > "That said, I'm NOT against the idea in general" > > as it should obviously be wiped out sooner rather than later. But this > is exactly the case when my personal humble opinion conflicts with the > management one. But let's hear other opinions as well, I'm not a > dictator ;-) -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3942) Restore from gbak backup using service doesn't report an error
Restore from gbak backup using service doesn't report an error -- Key: CORE-3942 URL: http://tracker.firebirdsql.org/browse/CORE-3942 Project: Firebird Core Issue Type: Bug Components: GBAK Affects Versions: 2.5.1 Reporter: Pavel Cisar When database exists and isc_spb_res_create instead isc_spb_res_replace is specified, restore using service doesn't report any error, just silently does nothing. Although not confirmed, could it be a general issue with error reporting from gbak service? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Conversion of CVS to Subversion
Hi, I did the conversion of main Firebird modules to SVN. Dne 14.7.2012 17:19, Mark Rotteveel napsal(a): > Now that Jaybird 2.2 is released we want to migrate the CVS client-java > module to Subversion. Is there any documentation on how this was done > for firebird? Nope. As it was one-way, do-once process, there was no point to document it. However, I've used cvs2svn (see http://pypi.python.org/pypi/cvs2svn) and it wasn't so hard although it took a lot of time. But it took so long because the data volume was huge, so every test run took several hours. I also did thorough routine tests, as there was no margin for error (it was no replace but merge, as SVN was already used for other code) and I had to find optimal compromise between history detail (there was no point to migrate some ALPHA, BETA or even RC tags) and data volume, make changes in structure (CVS is flat while SVN isn't) etc. So it took about a month to prepare it, but final execution was over weekend. As Jaybird is small code base with not so huge history of changes like core engine, it should be much much easier for you. Also the cvs2svn evolved a lot since then. The cvs2svn creates a dump file that could be imported into svn (at least it was the way it works back then) via SourceForge shell service. Just make shure the import ADDs, not REPLACE the old repository :) It's also good to take full svn backup (not chekout) before merge. best regards Pavel Cisar IBPhoenix -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3882) Bopen doesn't use BPB to set BLOB type to isc_bpb_type_stream
Bopen doesn't use BPB to set BLOB type to isc_bpb_type_stream - Key: CORE-3882 URL: http://tracker.firebirdsql.org/browse/CORE-3882 Project: Firebird Core Issue Type: Bug Components: API / Client Library Affects Versions: 2.1.5, 2.0.7, 2.5.1, 3.0 Initial Reporter: Pavel Cisar Stream BLOBs are those ones that were *created* with isc_bpb_type_stream in Blob Parameter Block. API function Bopen specifically designed to make work with stream BLOBs more easy doesn't use BPB at all, so it in fact doesn't create/work with stream BLOBs. As a direct consequence of this bug API function isc_seek_blob (that works only on true stream BLOBs) will fail with error when one uses Bopen/BLOB_put/BLOB_get API family.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3867) Outdated error message
Outdated error message -- Key: CORE-3867 URL: http://tracker.firebirdsql.org/browse/CORE-3867 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.0.7, 2.5.1, 2.1.4, 2.5.0, 2.0.6, 2.1.3, 2.1.2, 2.0.5, 2.1.1, 2.1.0, 2.1.5 Reporter: Pavel Cisar Priority: Minor Error message for unsupported feature (335544378): ARRAY comparison erroneously state that: "BLOB and array data types are not supported for compare operation". BLOB comparison is supported at least since 2.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (PYFB-12) Support for Trace Service
Support for Trace Service - Key: PYFB-12 URL: http://tracker.firebirdsql.org/browse/PYFB-12 Project: Firebird driver for Python Issue Type: Improvement Reporter: Pavel Cisar Assignee: Pavel Cisar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (PYFB-11) Support for Firebird ARRAY datatype
Support for Firebird ARRAY datatype --- Key: PYFB-11 URL: http://tracker.firebirdsql.org/browse/PYFB-11 Project: Firebird driver for Python Issue Type: New Feature Reporter: Pavel Cisar Assignee: Pavel Cisar Priority: Minor Should be interface-compatible to KInterbasDB's implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (PYFB-8) Support for Firebird EVENTS
Support for Firebird EVENTS --- Key: PYFB-8 URL: http://tracker.firebirdsql.org/browse/PYFB-8 Project: Firebird driver for Python Issue Type: New Feature Reporter: Pavel Cisar Assignee: Pavel Cisar Should be interface-compatible to KInterbasDB's implementation.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (PYFB-9) Support for streamed BLOBs
Support for streamed BLOBs -- Key: PYFB-9 URL: http://tracker.firebirdsql.org/browse/PYFB-9 Project: Firebird driver for Python Issue Type: New Feature Reporter: Pavel Cisar Assignee: Pavel Cisar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (PYFB-10) Support for distributed transactions.
Support for distributed transactions. - Key: PYFB-10 URL: http://tracker.firebirdsql.org/browse/PYFB-10 Project: Firebird driver for Python Issue Type: New Feature Reporter: Pavel Cisar Assignee: Pavel Cisar Should be interface-compatible to KInterbasDB's implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] File system cache vs. Firebird page cache?
Dne 10.6.2011 10:41, Thomas Steinmaurer napsal(a): > Hello, > > has anybody run or has evidence on what type of caching should be > preferred in a high-load environment via the MaxFileSystemCache > firebird.conf parameter? > > Basically, I'm investigating different things on how to get the best ouf > of Firebird via configuration stuff (firebird.conf, page buffers, page > size ...) > > Target environment: 2.1 Classic, 2.5 Classic/SuperClassic on Windows. MaxFileSystemCache is intended for use with SuperServer, where really big FB cache on top of file system cache could be counter productive. Classic and SuperClassic work with very small FB cache (to conserve memory and lower IPC traffic to synchronize them between FB processes/threads). best regards Pavel Cisar IBPhoenix -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3451) Query with SP doesn't accept explicit plan
Query with SP doesn't accept explicit plan -- Key: CORE-3451 URL: http://tracker.firebirdsql.org/browse/CORE-3451 Project: Firebird Core Issue Type: Bug Affects Versions: 2.5.0 Reporter: Pavel Cisar Priority: Minor Test query for CORE-3450 doesn't accept explicit execution plan. select t2.fld1 from tmp_tbl2 t2 join tmp_tbl1 t1 on t1.fld1=t2.fld1 join tmp_sp1 on tmp_sp1.fld1=t1.fld2 join tmp_tbl3 t3 on t3.fld1=t1.fld3 where t2.fld2=2 PLAN JOIN (JOIN (TMP_SP1 NATURAL, T1 INDEX (TMP_TBL1_FLD2)), T2 INDEX (TMP_TBL2_FLD1), T3 INDEX (TMP_TBL3_FLD1)) ; return error: Engine Code: 335544569 Engine Message : Dynamic SQL Error SQL error code = -104 Invalid command there is no alias or table named TMP_SP1 at this scope level The explicit plan is exactly the one returned for the query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3450) Inefficient optimization (regression)
Inefficient optimization (regression) - Key: CORE-3450 URL: http://tracker.firebirdsql.org/browse/CORE-3450 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.0 Reporter: Pavel Cisar Test case: /* INIT */ create table tmp_tbl1 (fld1 integer, fld2 integer, fld3 integer); create index tmp_tbl1_fld1 on tmp_tbl1(fld1); create index tmp_tbl1_fld2 on tmp_tbl1(fld2); commit; create table tmp_tbl2 (fld1 integer, fld2 integer); create index tmp_tbl2_fld1 on tmp_tbl2(fld1); create index tmp_tbl2_fld2 on tmp_tbl2(fld2); commit; create table tmp_tbl3 (fld1 integer); create index tmp_tbl3_fld1 on tmp_tbl3(fld1); commit; set term ^; create or alter procedure tmp_sp1 returns (fld1 integer) as begin fld1=1; suspend; end ^ create or alter procedure tmp_sp2 as declare variable I integer; begin i=0; while (i<1) do begin i=i+1; insert into tmp_tbl1 values (:i, 1, 3); end i=0; while (i<10) do begin i=i+1; insert into tmp_tbl2 values (:i, 2); end insert into tmp_tbl3 values (3); end ^ set term ;^ commit; execute procedure tmp_sp2; commit; SET STATISTICS INDEX TMP_TBL1_FLD1; SET STATISTICS INDEX TMP_TBL1_FLD2; SET STATISTICS INDEX TMP_TBL2_FLD1; SET STATISTICS INDEX TMP_TBL2_FLD2; SET STATISTICS INDEX TMP_TBL3_FLD1; commit; -- Test: select t2.fld1 from tmp_tbl2 t2 join tmp_tbl1 t1 on t1.fld1=t2.fld1 join tmp_sp1 p1 on p1.fld1=t1.fld2 join tmp_tbl3 t3 on t3.fld1=t1.fld3 where t2.fld2=2; FB 1.5: PLAN JOIN (TMP_SP1 NATURAL,JOIN (T2 INDEX (TMP_TBL2_FLD2),T1 INDEX (TMP_TBL1_FLD2,TMP_TBL1_FLD1),T3 INDEX (TMP_TBL3_FLD1))) Reads = 0 Writes 0 Fetches = 366 FB 2.5: PLAN JOIN (JOIN (TMP_SP1 NATURAL, T1 INDEX (TMP_TBL1_FLD2)), T2 INDEX (TMP_TBL2_FLD1), T3 INDEX (TMP_TBL3_FLD1)) < different plan Reads = 0 Writes 0 Fetches = 40094 <- causes significant performance degradation when executed many times under load -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3449) Wrong or missing IS NULL optimization (regression)
Wrong or missing IS NULL optimization (regression) -- Key: CORE-3449 URL: http://tracker.firebirdsql.org/browse/CORE-3449 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.0 Reporter: Pavel Cisar Test case: /* prepare */ create table tmp_tbl1 (fld1 integer, fld2 integer, fld3 integer); create index tmp_tbl1_fld123 on tmp_tbl1(fld1, fld2, fld3); create index tmp_tbl1_fld2 on tmp_tbl1(fld2); commit; set term ^; create or alter procedure tmp_sp1 as declare variable I integer; begin i=0; while (i<1) do begin i=i+1; insert into tmp_tbl1 values (1, :i, 2); end end ^ set term ;^ commit; execute procedure tmp_sp1; commit; SET STATISTICS INDEX TMP_TBL1_FLD123; SET STATISTICS INDEX TMP_TBL1_FLD2; commit; /* test */ select count(*) from tmp_tbl1 where fld1=1 and fld2 is null; /* 1.5: PLAN (TMP_TBL1 INDEX (TMP_TBL1_FLD2,TMP_TBL1_FLD123)) COUNT 0 Current memory = 53311040 Delta memory = 16164 Max memory = 53467732 Elapsed time= 0.01 sec Buffers = 6000 Reads = 0 Writes 0 Fetches = 55 2.5: PLAN (TMP_TBL1 INDEX (TMP_TBL1_FLD123)) <<<<< different plan COUNT 0 Current memory = 53597056 Delta memory = 21576 Max memory = 53936000 Elapsed time= 0.01 sec Buffers = 6000 Reads = 0 Writes 0 Fetches = 20022 <<<<<<< causes significant performance degradation when executed many times under load */ Under v2.5 FLD2 IS NULL predicate is either not optimized using index or is handled wrongly. Note that there are no rows with NULL value in FLD2, so there shouldn't be so much fetches. The number of fetches indicate that only fld1=1 condition is handled via index (there is only 1 value in all 10k rows). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
