Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

On 5/2/2014 3:25 PM, Vlad Khorsun wrote: >> OK, the alternative to record lookups is to store the transaction id in >> index. This would require an index insertion for all indexes defined on >> a table even if the key value didn't change. It would also require a >> corresponding index deletion fo

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

On 5/2/2014 3:25 PM, Vlad Khorsun wrote: >> OK, the alternative to record lookups is to store the transaction id in >> index. This would require an index insertion for all indexes defined on >> a table even if the key value didn't change. It would also require a >> corresponding index deletion fo

Re: [Firebird-devel] Feature request & discussion (Reply to Planning the post v3 development)

On 5/1/2014 11:45 PM, Dmitry Yemanov wrote: > 2- In an version based database like Firebird each row will need to be read > to confirm the current value of the target field. > It's not about version based databases, it's just about our index > implementation. And there are possibilities to avoid r

Re: [Firebird-devel] Replication

On 4/29/2014 8:38 AM, Dimitry Sibiryakov wrote: > 29.04.2014 14:24, Carlos H. Cantu wrote: >> You are right about the DB design, but that's up to the user. You >> dont and should not worry with this. > But the one who implements built-in replication will have to worry about > conflict > handli

Re: [Firebird-devel] Planning the post v3 development

On 4/28/2014 10:29 AM, Carlos H. Cantu wrote: > 3) A way to schedule some tasks direct in FB, for example, > running procures, sweeps, statistics recalcs, etc. at specific > scheduled days/times. What would be accepted as a task could be > limited to whatever you guys thinks that would be "safe" to

Re: [Firebird-devel] Planning the post v3 development

On 4/24/2014 6:19 AM, Dmitry Yemanov wrote: All, We're getting closer to the v3.0 feature freeze which is going to happen this summer. Everything roadmapped for v3 but not implemented before the deadline will be postponed. The next-after-v3 release is likely to incorporate most of the postponed

Re: [Firebird-devel] Upgrading idpl 1.0 license to 2.0 so we can be gpl compatible

they are sued. > provides compatibility with the Apache and GPL licenses, making code > reuse and redistribution easier. > > On Fri, Apr 4, 2014 at 12:57 AM, Jim Starkey wrote: >> On 4/3/2014 5:16 AM, marius adrian popa wrote: >>> I repost it here from Firebird-general >>>

Re: [Firebird-devel] How to? Coordinating transactions for multipleconnections in single call

On 4/4/2014 9:53 AM, Leyne, Sean wrote: > Adriano, > >> Instead of get from info and pass "everything" (possible MBs?) in the TPB, >> isn't possible to pass only the "base transaction number" of cloned >> transaction, and them the engine instances dumps necessary information, >> like with monitorin

Re: [Firebird-devel] No-lock Memory Pools

On 4/4/2014 9:43 AM, Dimitry Sibiryakov wrote: > 04.04.2014 15:37, Alex Peshkoff wrote: >> On 04/04/14 17:01, James Starkey wrote: >>> An alternate solution that is close is thread specific sub-pools, which is >>> nice because a thread specific sub-pool doesn't even need interlocked >>> instruction

Re: [Firebird-devel] Upgrading idpl 1.0 license to 2.0 so we can be gpl compatible

On 4/3/2014 5:16 AM, marius adrian popa wrote: > I repost it here from Firebird-general > > Just noticed Mozilla license v1.1 > http://opensource.org/licenses/MPL-1.1 was upgraded to v 2.0 maybe is > time for firebird project to do so for all new code (This license has > been superseded by the Moz

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

On 4/3/2014 11:58 AM, Vlad Khorsun wrote: >> Sean, the solution is simple and elegant: Capture the transaction state >> information from the lead transaction using the transaction info >> mechanism then import it to secondary connection transactions with the >> transaction parameter block. >

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

On 4/3/2014 11:42 AM, Dimitry Sibiryakov wrote: > 03.04.2014 17:37, Jim Starkey wrote: >> But don't you have exactly the same problems on the replica unless you >> take it off line? > No. Replica is not under load, it can handle a concurrency level > transaction as l

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

On 4/3/2014 11:19 AM, Dimitry Sibiryakov wrote: > 03.04.2014 17:08, Jim Starkey wrote: >> Sean has done an exemplary job of explaining his abstract problem >> (capturing a consistent snapshot of a subset of data), the constraints >> (gotta be fast), and a proposed solut

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

Sorry (well, not really) about the top posting. It's the way the rest of the world works, and for good reasons. I think "idiot" is completely inappropriate. I'd go for arrogant, close minded, and short sighted. And probably self-centered. The challenge in all design is to discern what a user

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

Sean, the solution is simple and elegant: Capture the transaction state information from the lead transaction using the transaction info mechanism then import it to secondary connection transactions with the transaction parameter block. Internally, creation a transaction object using the lead

Re: [Firebird-devel] How to? Coordinating transactions formultiple connections in single call

On 4/2/2014 8:01 PM, Leyne, Sean wrote: > >> you can adapt my FAQ example >> http://itstop.pl/en-en/Porady/Firebird/FAQ2/FIRST-SNAPSHOT >> but starting all transactions as "First Snapshot" transactions in many >> connections where system is still working i suppose is quite to impossible >> with it.

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

On 4/2/2014 7:05 PM, Vlad Khorsun wrote: >> On 4/2/2014 5:28 AM, Vlad Khorsun wrote: C I think it will be not easy to implement from the Y-valve point of view - i see no simple way to pass handles from one process (coordinator) to another (worker). Especially, in the

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

On 4/2/2014 5:28 AM, Vlad Khorsun wrote: >> C >> I think it will be not easy to implement from the Y-valve point of view >> - i see no simple way to pass handles from one process >> (coordinator) to another (worker). Especially, in the case of Classic Server. >> >> Instead, i think, we c

Re: [Firebird-devel] The invisible generator and the rdb$ prefix

The wolf in Manchester pleads not guilty. A cursory examination of the Vulcan code exposed the following code snippet in MET_lookup_index_name: if (!gen_id) { strcpy (name, "RDB$GENERATORS"); return; } Any student of wolf-code will understand that the wo

Re: [Firebird-devel] Is newly allocated memory initialized to zero?

My original memory allocator reliably initialized memory to all zeros. It saves a lot of code. Note that Java follows the same convention for the same reasons. All that said, the C++ "new" does not, and while I from time to time use a custom, high performance "new", it is just too dangerous to

Re: [Firebird-devel] RFC: stop fiddling with sys tables

On 3/21/2014 12:18 PM, Leyne, Sean wrote: > >> Sub-objects (parameters, columns, constraints) and attributes (say, routine >> source) are not tracked directly. >> >> You should read system tables and compare (in before and after triggers). > How? > > Yes I can create a trigger, but I can't read the

[Firebird-devel] Cycle Manager

I was thinking about your mutex protected linked list when it occurred to me that Firebird might benefit from a piece of technology I call "cycle lock." Here is a description of the motivation and the technique. Falcon, NuoDB, and AmorphousDB all use a hash table to map transaction ids into tr

Re: [Firebird-devel] RFC: stop fiddling with sys tables

User updateable system tables seemed like a good way to build a access language neutral database engine for Rdb/ELN and Interbase. The Rdb/VMS guys never warmed to the concept, and developed an MBLR (metadata BLR) mechanism. It wasn't a big hit, either, and I eventually created DYN for many o

Re: [Firebird-devel] Y-classes trickery

On 3/18/2014 7:47 AM, Alex wrote: > On 03/18/2014 01:26 PM, Dimitry Sibiryakov wrote: >> Back to the question: >> >> 17.03.2014 12:30, Alex Peshkoff wrote: Besides, storing reference to object already increment its > usage counter, so nobody can free the object during wrapper's l

Re: [Firebird-devel] MySQL versus Firebird

Ann and I know Peter and his wife Trudy very well. For most of the time we were there, Trudy was the other woman in engineering. Peter is much more of a theoretician than a developer, so he may not be fully up to speed on the practical implications of some of this stuff. The MySQL engineering

Re: [Firebird-devel] MetadataFromBlr diagnostics

On 3/6/2014 10:39 AM, Alex Peshkoff wrote: > On 03/06/14 19:30, Dimitry Sibiryakov wrote: >> 06.03.2014 16:21, Alex Peshkoff wrote: >>> BTW, when using new interface message about bad SQLDA looks silly. >>> Who has an idea what to do with it? >> Replace them with complaints about BLR. > Also f

Re: [Firebird-devel] ICU Data table customization

Would it be feasible to restructure ICU has a master DLL/shared image plus a DLL/shared image per character set loaded on demand? If so, Firebird could be packaged with a small subset containing popular languages with others available for download somewhere. On 2/19/2014 10:30 AM, Paul Reeves

Re: [Firebird-devel] Update ICU in Windows

Does Firebird use cmake? If so, cmake has a "find_package" mechanism that is platform, compiler, and version independent. If Firebird doesn't use cmake, well, it should. I haven't looked at this, but there is a package definition at https://github.com/julp/FindICU.cmake. On 2/14/2014 11:57

Re: [Firebird-devel] Some aspects of the optimizer hints

On 1/7/2014 3:45 PM, Mark Rotteveel wrote: > The fact that the optimizer will (or should) optimize it in a specific > way does not mean you should abuse also it to get the optimizer to use > a specific optimization. It can lead to hard to find bugs in the > future, for example if you used SELEC

Re: [Firebird-devel] Some aspects of the optimizer hints

On 1/7/2014 1:14 PM, Simonov Denis wrote: >> Why it have to have fixed position? Cannot btyacc syntax parser handle a >> clause anywhere?.. > > Course parser can parse and tips from various places, but I look at it > from the perspective of the application developer. It is much easier to > remove

Re: [Firebird-devel] Some aspects of the optimizer hints

On 1/2/2014 8:10 AM, Simonov Denis wrote: > Dmitry Yemanov писал(а) в своём письме Thu, 02 Jan > 2014 15:55:57 +0400: > > >> This makes it necessary to allow the FIRST ROWS mode when it's needed. >> I'm proposing the following: >> >> 1) FIRST ROWS mode is implicitly used when the FIRST / ROWS clau

Re: [Firebird-devel] RFC: Data page allocation algorithm

I'm not sure this will change much. It will reduce the number of times that the PIP needs to be referenced, which will save a little CPU. Careful write needs to be preserved in all cases, so the PIP will always need to be written before the data pages and associated pointer pages. But since

Re: [Firebird-devel] firebird fails to build if "-Werror=format-security" flag is used.

For what it's worth, gpre was my very first C program in 1984. It was written on a 16 bit Unix running on a DEC Pro/350 (a pdp-11). It's coming up on its 30th birthday next September, so be kind to it. It's probably among the oldest pieces of working software on the planet. On 12/5/2013 3:28

Re: [Firebird-devel] Compatibiliti fb3 and previous

On 12/3/2013 12:31 PM, Dimitry Sibiryakov wrote: > 03.12.2013 18:25, Dmitry Yemanov wrote: >> Doesn't it mean that such an application will be always passing SQL_LONG >> to execute/fetch calls? > No, it is much more stupid. Application get ISC_INT64 from API, derive > fields type > fbBigint fr

Re: [Firebird-devel] Compatibiliti fb3 and previous

On 12/3/2013 6:24 AM, Mark Rotteveel wrote: > On Tue, 03 Dec 2013 12:10:30 +0100, "liviusliv...@poczta.onet.pl" > wrote: >> Hi, >> >> Will be good to have some configurable option for data type result for >> count(*). >> >> In FB3 result rype is bigint in previous it was integer. >> >> All project

Re: [Firebird-devel] FWD: Re: Compatibility FB3.0 boolean and Interbase

On 11/13/2013 10:55 AM, Dimitry Sibiryakov wrote: > 13.11.2013 16:50, Jim Starkey wrote: >> OK, I give up. How can there be different UTF-8 character sets when >> UTF-8 is defined by inter-galactic standard? > Our utf-8 charset has different id than IB&#x

Re: [Firebird-devel] FWD: Re: Compatibility FB3.0 boolean and Interbase

On 11/13/2013 4:01 AM, Dimitry Sibiryakov wrote: > 13.11.2013 9:17, Alex wrote: >> For me main problem is that we do not know format of interbase messages >> when boolean is used in them. We do not know alignment rules. We know >> _nothing_ about internals of boolean implementation in interbase. >

Re: [Firebird-devel] Changes with handling DB_KEY?

Jaybird? Now that is confusing. Jaybird was the DEC internal code name for what became Rdb/ELN, the immediate precursor to what became Interbase. On 8/4/2013 8:39 AM, Mark Rotteveel wrote: > Has anything changed in Firebird 3.0 with the stability of RDB$DB_KEY or > how RDB$DB_KEY works? > > Jayb

Re: [Firebird-devel] Metadata cache

On 11/1/2013 6:49 AM, Alex Peshkoff wrote: > On 10/29/13 20:01, Dimitry Sibiryakov wrote: >> Hello, All. >> >> Did someone try to cut subj off and feed metadata from system tables >> directly every >> time when they are needed? >> > May be Jim? About 25 or more years ago :) NFW. That's

Re: [Firebird-devel] Complex String Decoding

: > Den 2013-09-06 00:29 skrev Jim Starkey såhär: >> A couple of folks asked, so here it is. >> >> The scheme centers around pattern strings. A pattern string represents >> one of any number of possible interpretations of a target string. A >> pattern string consi

[Firebird-devel] Complex String Decoding

A couple of folks asked, so here it is. The scheme centers around pattern strings. A pattern string represents one of any number of possible interpretations of a target string. A pattern string consists of punctuation characters and the characters A and 9 representing consecutive sequences of

Re: [Firebird-devel] Record Encoding

On 9/5/2013 4:28 AM, Alex Peshkoff wrote: > On 09/04/13 18:11, Jim Starkey wrote: > >> So here's another seriously heretical thought. If you're planning for >> Firebird to hang around another 27 years, it's time to define a modern >> OO API that is easy to

Re: [Firebird-devel] Record Encoding

A clob is nothing but a blob that is thought to be character. On 9/4/2013 6:40 AM, Adriano dos Santos Fernandes wrote: > On 04/09/2013 05:09, Alex Peshkoff wrote: >> On 09/04/13 11:53, Dmitry Yemanov wrote: >>> 04.09.2013 11:43, Alex Peshkoff wrote: May be in that case next step? Keep declari

Re: [Firebird-devel] Record Encoding

Unbounded types work very badly with the SQLDA. The original SQLDA was lifted verbatim from the DB2 spec, circa 1985, because I wanted something more or less standard. It was pretty much awful then and it hasn't gotten much prettier since. On the other hand, it's what everything uses for Fir

Re: [Firebird-devel] Record Encoding, was Unicode UTF-16 etc

On 9/3/2013 8:02 AM, Alex Peshkoff wrote: > On 09/03/13 13:21, Dmitry Yemanov wrote: >> 03.09.2013 11:13, Alex Peshkoff wrote: >> >>> That's definitely a candidate for next ODS. But I see one problem - >>> currently all (or at least most of all) record buffers are allocated at >>> prepare time. Wit

[Firebird-devel] Record Encoding, was Unicode UTF-16 etc

full advantage of this. On 8/31/2013 7:46 AM, Ann Harrison wrote: On Aug 31, 2013, at 4:55 AM, Mark Rotteveel wrote: On 29-8-2013 17:41, Jim Starkey wrote: Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit Unicode. The reason is simple: There are enough single byte

Re: [Firebird-devel] For discussion: allowing multiple changes in ALTER COLUMN clause (ALTER TABLE)

OK, here's another "humble" suggestion that folks might want to consider for a future version: Support an "upgrade " syntactically parallel to "create ". The "upgrade" version, however, takes the existing object, compares it to the described object, and makes any changes necessary. If they a

Re: [Firebird-devel] Unicode UTF-16 etc

Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit Unicode. The reason is simple: There are enough single byte characters -- punctuation, control characters, and digits -- stay as single bytes, double byte characters are a wash, and the single byte characters generally bal

Re: [Firebird-devel] Direct System Table Update

Sorry about the long delay, but we were way down east in Maine. An essential flaw that Firebird inherited from Interbase is the way system tables are initialized at server startup. The current scheme makes it extremely difficult to make changes to the system tables without declaring a new ODS,

Re: [Firebird-devel] Direct System Table Update

BTW, I'm really sorry I implemented updatable system tables. So much more grief than benefit. I never did it again and never missed it. But on the subject of blowing things, I also regret not adding a multi-level namespace for system objects. We didn't in Interbase for runtime compatibility

Re: [Firebird-devel] event connection lost after long inactivity

Guys, it was close to 30 years ago, but my best guess was that it would tell the AST that the event was cancelled so it probably wouldn't be a good idea to requeue the events. It eliminates a potentially nasty race condition when events are posted while another thread is trying to cancel. Retu

Re: [Firebird-devel] Fwd: RC4 for encryption?

records, average encoding lengths were about 60% the length of Firebird's run length encoding. XDR is getting rather long in tooth, don't you think? On 5/28/2013 6:54 AM, Alex Peshkoff wrote: On 05/27/13 20:10, Jim Starkey wrote: Is the attach package encrypted with the session key?

Re: [Firebird-devel] Fwd: RC4 for encryption?

tions? > RC4 is not more than default wire encryption plugin - if you really do > not trust it you can easily write your own. > > > On 05/26/13 21:36, Jim Starkey wrote: > >> I don't know what Firebird is now using for password validation, but I >> strongly suggest

Re: [Firebird-devel] Fwd: RC4 for encryption?

On 5/27/2013 3:53 AM, Mark Rotteveel wrote: > On Sun, 26 May 2013 13:36:36 -0400, Jim Starkey > wrote: > Read the fine print. To break a message, you need 2^30 encrypted > versions of a message containing a 256 byte constant block starting at a >> fixed position. Nice theore

Re: [Firebird-devel] Fwd: RC4 for encryption?

From: *Mark Rotteveel* mailto:m...@lawinegevaar.nl>> Date: Sun, May 26, 2013 at 11:53 AM Subject: [Firebird-devel] RC4 for encryption? To: For discussion among Firebird Developers > If I understand it correctly, the new wire encryption of FB 3 uses

<    1   2   3