Re: [Firebird-devel] Raising the BLR level
> -Original Message- > From: Ann Harrison [mailto:aharri...@nuodb.com] > Sent: Martes, 06 de Marzo de 2012 19:10 > > Having started this discussion by agreeing with Claudio, now > let me suggest that I was probably wrong. I'll think about it > a bit more, but finding a way of extending blr compatibly > seems like a much better idea. That lets old databases > continue to work and avoids the whole discussion of what > other features to drop. More tomorrow. Ann, I hope you will come with an interesting solution. However, let's recap: - If the BLR version number doesn't serve to upgrade BLR, then it's completely useless. - The original proposal was to upgrade BLR, nothing more. Other person wanted to drop BLR v4 and then dialect 1 and the discussion became fuzzy and out of bounds. The original proposal NEVER intended to remove the old BLR and the old dialect. - The only problem that a new BLR version doesn't solve is when you want to go back to a previous server version, but if you try to use some FB3's new DSQL feature in FB2.0, it's going to fail, right? So, what's different? Some new BLR verbs don't exist in the original FB1.0, despite the BLR version not being increased. When BLR v5 was invented, older servers speaking BLR v4 couldn't understand it... but the world didn't explode. C. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
On 03/06/12 23:01, Leyne, Sean wrote: >> -Original Message- >> From: Claudio Valderrama C. [mailto:cva...@usa.net] >> Sent: Tuesday, March 06, 2012 6:29 AM >> >>> -Original Message- >>> From: Alex Peshkoff [mailto:peshk...@mail.ru] >>> Sent: Martes, 06 de Marzo de 2012 8:06 >>> >>> Also want to agree, but I remember there were some real reasons >>> (unfortunately do not remember them) making people stay with dialect1. >>> May be somebody remembers that reasons? >> I think that the different treatment of date format (when converting to >> text) and datetime storage (double v/s int64) wasn't the primary motivation. >> >> The main reason was that dialect 3 imposes exact numerics rules for >> multiplication and division and we don't have enough bits to account for all >> cases (we would need internally int128 or somewhat alike). Also, division >> becomes C-like for integer numbers. > This is why BroadView hasn't made the move from Dialect 1. The numeric rules > imposed by Dialect 3 would have required a huge amount of re-coding and > testing to ensure that our calculations/reports generated the expected > results. > > BTW, unless I have missed something, there is no posting which has said that > Dialect 1 needs to be eliminated in order for the BLR version to be > increased. May be I was not specific enough... At least for today dialect 1 means blr 4, dialect 3 means blr 5. Suppose this can be reworked, but far not trivially. > So, changing the BLR levels has no dependencies on the question of on-going > support for Dialect 1. The subject of dialects came up due to a question > from Alex about whether the support for the old BLR versions was necessary > for Dialect 1. > > > As for Dialect 1, it is my opinion that the Dialect 3 intermediate numeric > rules are half-baked (at best) and that until such time as they have been > have been made intelligent that support for Dialect 1 needs to be maintained > (do I hear a Dialect 4? == Dialect 1 math rules, plus 'new' Boolean, Date, > Time, Timestamp and INT64 datatypes). > This may be a way to go. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
On 03/06/12 23:56, Dimitry Sibiryakov wrote: > 06.03.2012 20:54, Adriano dos Santos Fernandes wrote: >> It will be 0.333... (up to the maximum NUMBER scale precision). >> >> The thing is that for operations like addition, subtraction, NUMBER will >> work like NUMERIC (i.e., it's results are more precise than DOUBLE). >In this case much easier is to change intermediate result of division to > floating-point > type. No need to introduce new type for this. > There is one more problem with this solution - migrating old databases to new datatypes is nightmare. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
07.03.2012 10:03, Alex Peshkoff wrote: > At least for today dialect 1 means blr 4, dialect 3 means blr 5. Suppose > this can be reworked, but far not trivially. Weren't there plans to exclude BLR from chain SQL-BLR-EXE at all?.. -- SY, SD. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
On 03/07/12 13:11, Claudio Valderrama C. wrote: >> -Original Message- >> From: Ann Harrison [mailto:aharri...@nuodb.com] >> Sent: Martes, 06 de Marzo de 2012 19:10 >> >> Having started this discussion by agreeing with Claudio, now >> let me suggest that I was probably wrong. I'll think about it >> a bit more, but finding a way of extending blr compatibly >> seems like a much better idea. That lets old databases >> continue to work and avoids the whole discussion of what >> other features to drop. More tomorrow. > Ann, I hope you will come with an interesting solution. However, let's > recap: > > - If the BLR version number doesn't serve to upgrade BLR, then it's > completely useless. > - The original proposal was to upgrade BLR, nothing more. Other person > wanted to drop BLR v4 and then dialect 1 and the discussion became fuzzy and > out of bounds. The original proposal NEVER intended to remove the old BLR > and the old dialect. > - The only problem that a new BLR version doesn't solve is when you want to > go back to a previous server version, but if you try to use some FB3's new > DSQL feature in FB2.0, it's going to fail, right? So, what's different? Some > new BLR verbs don't exist in the original FB1.0, despite the BLR version not > being increased. When BLR v5 was invented, older servers speaking BLR v4 > couldn't understand it... but the world didn't explode. Claudio, today BLR version defines dialect used. That's why discussion was raised. Some related questions are raised: - Are we going to break this relationship with BLR version6? If not, are we going to introduce new dialect with ti? - If we break that relationship - what dialect will be used for requests in BLR6? Or probably we should use absolutely new method for deciding about request's dialect? I agree that to enhance limits changing BLR version looks like the most native approach. But unfortunately that version is also used to specify request's dialect. Therefore question about dialects was raised here. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
On 03/07/12 13:05, Dimitry Sibiryakov wrote: > 07.03.2012 10:03, Alex Peshkoff wrote: >> At least for today dialect 1 means blr 4, dialect 3 means blr 5. Suppose >> this can be reworked, but far not trivially. >Weren't there plans to exclude BLR from chain SQL-BLR-EXE at all?.. > There were such plans, but if we decide ti implement all plans in FB3 afraid we will not have it for too long time... -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Raising the BLR level
07.03.2012 10:14, Alex Peshkoff wrote: > Some related questions are raised: If we talk only about BLR generated and executed inside of server, I would say "generate BLR6 always for any SQL dialect", but with BLR generated or interpreted in client library there is a matter of compatibility with old servers. -- SY, SD. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ON CONNECT trigger and service attatchments
Hello, sorry, but I'm able to start a user trace session (=service attachment) without the trigger firing. I'm using Thomas' FB TraceManager. This might be an intended feature. Is it? > On 02/27/12 18:19, Björn Reimer wrote: >> Hello, >> should a trigger like the following on fb 2.5.(2 snapshot) fire when >> attaching via service api? It does not in my tests. >> SET TERM ^ ; >> CREATE OR ALTER TRIGGER DB_BI0 >> ACTIVE ON CONNECT POSITION 0 >> AS >> begin >> if (upper(current_role) = 'NONE') then >> EXCEPTION PARAMINVALID 'Please use a role...'; >> end >> ^ >> SET TERM ; ^ >> Why? >> I can imagine that there might be problems because of the context (No >> transaction ...) but such tests like above should work, don't they? > Works for me: > fbs2 bin # ./gbak -z -se service_mgr -b employee e.bak > gbak:gbak version LI-V2.5.2.26422 Firebird 2.5 > gbak: ERROR:exception 8 > gbak: ERROR:PARAMINVALID > gbak: ERROR:Please use a role... > gbak: ERROR:At trigger 'DB_BI0' line: 5, col: 37 > gbak:Exiting before completion due to errors > fbs2 bin # > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Björn Reimer - RRZE -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] gbak improvement
restore speed is important for big databases. It's a pain to wait 7 hours for restore to complete (~3 hours for data import and ~4 hours for index creation). Usually those big databases are already on fastest disk arrays companies can afford (and in addition servers have lots of RAM for caching). From what I've seen in production, during index creation CPU usage is ~99% (there is very little disk access). So I believe that making index creation multi-threaded and allowing it to run on many cores simultaneously would help significantly. So in the above real life example on 16 core server we could potentially decrease index creation time from 4 hours to 15..30 minutes, thus whole restore process could become twice faster (3.5 instead of 7 hours) -Original Message- From: Ann Harrison [mailto:aharri...@nuodb.com] Sent: Friday, February 24, 2012 6:35 PM To: For discussion among Firebird Developers Subject: Re: [Firebird-devel] gbak improvement Nick, > > When gbak finishes the actual data part of the restore it then creates all > the indexes, could it do that in parallel based on the number of processors > available. > It seems daft that I have to wait for each index to be built, one at a time, > when the server has several processors doing nothing As others have said, the cost of building an index is primarily the cost of reading the data, so building indexes in parallel on separate threads is unlikely to help. Building indexes incrementally as the data is stored (as someone else suggested) will be slow and build less dense indexes than the current method which requires sorting the data. What might help, but would require engine support is the ability to build two indexes on the same data with a single read of a table. Cheers, Ann -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Password encoding
On 03/01/12 20:48, Adriano dos Santos Fernandes wrote: > So, the password (and all other data) is converted if > isc_dpb_utf8_filename is not used. This may have bugs, specially in the > services mode, I'd say. When converting strings in DPB to UTF8, we touch not only password but a number of other data like file names. I wonder - what should be done with SPB? The answer is not trivial cause initially services API was described as 'file name as _server_ can see it'. Therefore the question is - does server-side encoding also fit in to that 'as _server_ can see it'? -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Password encoding
07.03.2012 16:41, Alex Peshkoff wrote: > Therefore the question > is - does server-side encoding also fit in to that 'as_server_ can see it'? I would say that if you use unicode routines for file I/O you won't miss. -- SY, SD. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
