[Firebird-devel] [FB-Tracker] Created: (CORE-4631) Lock manager out of room error hides the real cause of this problem
Lock manager out of room error hides the real cause of this problem - Key: CORE-4631 URL: http://tracker.firebirdsql.org/browse/CORE-4631 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3, 2.1.6, 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5 Reporter: Dmitry Yemanov Priority: Minor When the shared memory region backing the lock table cannot be remapped, the status vector returns the error message (lock manager out of room), but it lacks any low-level details (e.g. OS level error) causing this particular problem. This is mostly fixed in v3, but some cases are not covered there either. -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Reopened: (CORE-4602) RemoteServicePort is not working
[ http://tracker.firebirdsql.org/browse/CORE-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Yemanov reopened CORE-4602: -- Fix Version/s: (was: 3.0 Beta 2) Sean, pay attention to the build numbers. It works OK in official Beta (earlier build) but fails in the later build (snapshot). So you cannot resolve it as fixed, actually it's a recent regression. RemoteServicePort is not working Key: CORE-4602 URL: http://tracker.firebirdsql.org/browse/CORE-4602 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 RC 1 Environment: Windows 8.1 x64 , Firebird 3.0.0.31397 32bit Reporter: Mercea Paul Setting different value for RemoteServicePort in firebird.conf has no effect. Firebird runs on 3050. I have Firebird 2.5.2 32 bit installed, but stoped. FB3, start running on 3050 with any value on RemoteServicePort (3033,3053,etc). -- 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=164703151iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Firebird 3.0 Beta 1 release is available for testing
Firebird Project announces the first Beta release of Firebird 3.0, the next major version of the Firebird relational database, which is now available for testing. This Beta release demonstrates the features and improvements currently under development by the Firebird development team. Our users are appreciated giving it a try and providing feedback here. Apparent bugs can be reported directly to the bugtracker. Beta releases are not encouraged for production usage or any other goals that require a stable system. They are, however, recommended for those users who want to help in identifying issues and bottlenecks thus allowing to progress faster through the Beta/RC stages towards the final release. Please read the Release Notes carefully before installing and testing this Beta release. Download page: http://www.firebirdsql.org/en/firebird-3-0-0-beta1/ Release Notes: http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_Beta1-ReleaseNotes.pdf -- Dmitry Yemanov -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Tackling CORE-4526 (OFFSET FETCH)
30.11.2014 15:37, Mark Rotteveel wrote: Well, that was quick ;) Should I go and implement it anyway, or do we leave this until it is reported against an actual 3.0 release? So far it's about pure artificial testing, not something really used in production. So I'd wait a bit more ;-) Dmitry -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Tackling CORE-4526 (OFFSET FETCH)
Mark,
I'm looking at the patch, please be patient ;-)
Any news on this?
I don't have any major problems with the patch. Just a few questions:
1) Why have you decided to extend select_expr via duplication rather
than using something like this:
%type selectExprNode select_expr
select_expr
: with_clause select_expr_body order_clause limit_clause2
{
SelectExprNode* node = $$ = newNodeSelectExprNode();
node-querySpec = $2;
node-orderClause = $3;
node-rowsClause = $4;
node-withClause = $1;
}
;
%type rowsClause limit_clause2
limit_clause2
: rows_clause
{ $$ = $1; }
| result_offset_clause fetch_first_clause
{
if ($1 || $2) {
RowsClause* rowsNode = newNodeRowsClause();
rowsNode-skip = $1;
rowsNode-length = $2;
$$ = rowsNode;
} else {
$$ = NULL;
}
}
;
2) You have left non-standard ROWS clause for searched UPDATE/DELETE
statements because the standard does not define OFFSET/FETCH for them,
right? In this case, generic recommendation to use OFFSET/FETCH instead
of the [deperecated] ROWS looks too hard, as ROWS remains pretty valid
(and the only option) for UPDATE/DELETE.
Would it make sense to adapt OFFSET/FETCH for UPDATE/DELETE as well? Or
does it sound too weird for end-users (we're updating/deleting, not
fetching)?
3) New reserved words (OFFSET and ROW) should be added to the
keyword_or_column rule to simplify migration. That said, I'm wondering
why ROWS wasn't added there too in v2.0. Probably my oversight.
Dmitry
--
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=157005751iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Support for building Firebird with mingw-w64 toolchains.
23.11.2014 19:12, Alexpux wrote: I’m use Firebird about 7 years and now I’m interesting in build Firebird with mingw-w64 toolchains. Out of curiosity, why you need to build it yourself instead of using the official binaries? This is quite uncommon for Windows users. Most free databases build with mingw toolchains ok and used with it. I have no problems with mingw used for compilation, but why would one prefer using the mingw-produced binaries to the MSVC-produced ones? I’m wonder why Firebird developers want to remove mingw support at all. We remove support for something that's not maintained. If you will be maintaining the mingw port, your patches may be accepted. Did you test them with MSVC and Linux/gcc? Dmitry -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Support for building Firebird with mingw-w64 toolchains.
23.11.2014 20:23, Dimitry Sibiryakov wrote: No dependency on C++ runtime Is it really important for MSVC10 and higher? Dmitry -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4616) Server crashes while accessing context variables concurrently
Server crashes while accessing context variables concurrently - Key: CORE-4616 URL: http://tracker.firebirdsql.org/browse/CORE-4616 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3, 2.5.2 Update 1, 2.5.2 Reporter: Dmitry Yemanov Crash happens when one thread executes RDB$SET_CONTEXT: fb_inet_server!set_context fb_inet_server!CALL_UDFlong fb_inet_server!invoke fb_inet_server!FUN_evaluate fb_inet_server!EVL_expr fb_inet_server!EXE_assignment fb_inet_server!EXE_looper fb_inet_server!looper_seh fb_inet_server!execute_looper fb_inet_server!EXE_start fb_inet_server!execute_triggers fb_inet_server!EXE_execute_db_triggers fb_inet_server!JRD_start_multiple fb_inet_server!jrd8_start_transaction and another one retrieves the list of context variables due to the MON$ table request: fb_inet_server!Jrd::DatabaseSnapshot::putContextVars+0xc3 fb_inet_server!Jrd::DatabaseSnapshot::dumpData+0x128 fb_inet_server!Jrd::DatabaseSnapshot::blockingAst+0x9c fb_inet_server!Jrd::LockManager::blocking_action+0x134 fb_inet_server!Jrd::LockManager::signal_owner+0x37 fb_inet_server!Jrd::LockManager::post_blockage+0x1b4 fb_inet_server!Jrd::LockManager::wait_for_request+0x3d9 fb_inet_server!Jrd::LockManager::grant_or_que+0x8c fb_inet_server!Jrd::LockManager::enqueue+0x20e fb_inet_server!enqueue+0x51 fb_inet_server!LCK_lock+0x8f fb_inet_server!LCK_lock_opt+0x36 fb_inet_server!lock_buffer+0xdb fb_inet_server!CCH_fetch_lock+0x132 fb_inet_server!CCH_fetch+0x2d fb_inet_server!DPM_gen_id+0x152 Bug is caused by the lack of proper synchronization inside RDB$SET_CONTEXT. v2.1 and v3 are not affected. -- 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=157005751iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Tackling CORE-4526 (OFFSET FETCH)
11.11.2014 21:02, Mark Rotteveel wrote: Anyone? I'm looking at the patch, please be patient ;-) Dmitry -- 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://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] DROP USER delayed until commit?
09.11.2014 12:21, Mark Rotteveel wrote: I noticed that when dropping a user that does not exist (using DROP USER), the isc_gsec_err_rec_not_found error is not triggered on execute, but only on commit, which is rather unexpected and makes it harder to take appropriate actions. Why is this, and what is the state of the transaction afterwards (it seems to be active)? Anyone? Usual DDL is performed partially immediately (updates of system tables) and partially at commit. Validation is mostly done during the first phase, so errors like something not found are reported immediately. User management DDL, however, works exclusively at the commit time. This is because there are no local system tables to modify, they reside in security.fdb instead. The implementation is backed by the Services API calls and they don't support splitting execution into two steps. So we have to execute everything at once and this is done at commit to be consistent with other DDL (otherwise user management DDL would not be undoable at rollback after successful execution). As with any failure during commit, the transaction remains active and can be rolled back. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] request operations
04.11.2014 18:18, Dimitry Sibiryakov wrote:
Could someone explain meaning of each of the values?
enum req_s {
req_evaluate,
req_return,
req_receive,
req_send,
req_proceed,
req_sync,
req_unwind
};
req_evaluate - execute the node inside the main execution flow
req_return - node execution is finished and execution flow should be
redirected back to the parent node (to continue with the next node)
req_unwind - custom exception handling for the node, without an
exception handler it forces the whole execution tree to exit (i.e. node
- parent - parent - ... - out)
req_send / req_receive - handle in/out messages, IIRC they're mostly
bound to nod_send / nod_receive nodes
req_proceed - initial state to execute the request, also used together
with req_sync to implement SUSPEND (nod_stall)
Most of the new nodes need only evaluate / return / unwind to be
implemented. I don't remember us ever touching other request states.
Dmitry
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] View Creation error on Firebird 3 Snapshot 31387
Fabiano, I’m testing the new Firebird 3 Snapshot (31387) and I got a SP creation error that does not occur in FB 2.5.1. /Column unknown./ /ITENS.BDCODNAT./ This is an intended limitation to comply with the SQL specification (and other databases as well). from vef_emp_tmovseritens itens , vef_emp_tmovser MOV join VEF_BASE_TNATOP nat on (itens.bdcodnat = nat.bdcodnat) Mixed explicit and implicit joins should be used with care now. The join condition must include only the streams being joined (and outer streams, if exist). But A, B JOIN C actually means A, (B JOIN C) not (A, B) JOIN C. So your ON clause can reference MOV and NAT but it cannot reference ITENS. You probably need to move that condition to the WHERE clause instead. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Tackling CORE-4526 (OFFSET FETCH)
03.11.2014 23:14, Mark Rotteveel wrote: For implementing this I need to add two keywords: ROW and OFFSET (note: defined as reserved in SQL standard), but looking at the definition in keywords.cpp, I wonder what I need to use for version (1 or 2, or maybe a different value. Version 2. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Multiple instances under windows (was Re: UsingFirebird 3, beta 1 - installer report)
31.10.2014 20:19, Leyne, Sean wrote: The only issue is that the restart will not happen immediately, but after 1 minute (interval granularity is minutes, not seconds) Isn't zero interval allowed? Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Thought about constraint declarations for V4
Ann, I think it would be wise to add a [NO] VALIDATION modifier to constraint definitions, including NOT NULL and referential integrity definitions. In the presence of a VALIDATION modifier, Firebird would begin enforcing the constraint on commit (as now) and then start a pass to insure that the data complies with the constraint. I'd also be tempted to add a database configuration option that makes validation the default. AFAIK, all constraints backed by indices (i.e. PK/UK/FK) were always validated upon creation. Well, upon commit, actually. Starting with v3, we also enforce NOT NULL constraints. The engine validates data when NOT NULL is added for an already populated column (also at the commit time). So CHECK constraints seem to be the only ones that are not validated upon creation. Surely doable some day. The good question is whether we really should be supporting the NO VALIDATION option. Personally, I don't like that, however I know that some other databases has such a feature. If somebody had a real need for that, please describe your use case(s). All that said, I see no need for a configuration option. Validation should be always the default behavior. Any RDBMS is first of all about consistency and only then about performance. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Thought about constraint declarations for V4
28.10.2014 00:14, Thomas Steinmaurer wrote: Now while constraints are under discussion, if we could put deferred constraints into the nice to have pot ... ;-) Not for v4, sorry. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Multiple instances under windows (was Re: UsingFirebird 3, beta 1 - installer report)
28.10.2014 10:34, Martijn Tonies wrote: It would be nice to be able to easily control the instances from a small application. What's wrong with the Windows Service Manager? ;-) Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Thought about constraint declarations for V4
28.10.2014 12:35, Dimitry Sibiryakov wrote: Oracle?.. Their invalid DB objects aren't about consistency even in the smallest. Invalid metadata invalid data. We're speaking about the latter here. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Thought about constraint declarations for V4
28.10.2014 13:28, Adriano dos Santos Fernandes wrote: If user knows what he's doing, then the database is not validating, it's just wasting his time. I think there should be a NO VALIDATION option. Generally, I don't mind. My point was that *by default* VALIDATION should be implied and such clever users should explicitly specify their intentions by using the NO VALIDATION option. And that we shouldn't allow overriding NO VALIDATION to become a default behavior at the config level. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta 1: how to use additionalsecuritydatabases?
28.10.2014 18:28, Alex Peshkoff wrote: I understand that using mon$ tables could be better but afraid for FB3 time for such changes is gone. Feel free to modify SEC$USERS, if needed. I'm likely to commit changes for MON$ tables before Beta 2 as well. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta 1: how to use additionalsecuritydatabases?
28.10.2014 18:55, Alex Peshkoff wrote: What if I also add that info not to SEC$USERS but to MON$DATABASE? No problem, but what is that info? Name of the security db or what? I'm asking because we had plans to introduce all config settings (actual to this database) via a new MON$ table. So SecurityDatabase will surely be there and I don't want to duplicate this info. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta 1: how to use additionalsecuritydatabases?
28.10.2014 19:06, Martijn Tonies wrote: MON$SEC_DATABASE_USED values: DEFAULT / SECONDARY Maybe DEFAULT, SELF, OTHER? I may imagine cases when EUA and other-non-default dbs should be distinguished. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta 1: how to use additionalsecuritydatabases?
28.10.2014 19:19, Martijn Tonies wrote: What would self mean? Are the security tables inside the database you're connecting to? Self = EUA. Not just having security tables but actually known to be authenticated using them while connecting. And other non default would be a few databases using a single secondary security database? Other = everything neither self nor security3.fdb. So if you initialize some special security db to be used for few databases, then they will report OTHER (probably asking for a better name). Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta 1: how to use additionalsecuritydatabases?
28.10.2014 19:37, Dimitry Sibiryakov wrote: Why it is security.fdb, not security3.fdb then?.. Actually, it's security.db, not security.fdb ;-) security.db = $(dir_secDb)/security3.fdb Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 Build 31369 gbak crash
Fabiano, I’m testing the new Firebird 3.0 build 31369 and trying to restore a big database and at some point, creating an index gbak.exe crashes and database restore is interrupted. In the firebird.log I got 2 entries: FABIANOWed Oct 22 15:46:42 2014 Database: C:\SCI\BANCO\VSCI3.FDB internal Firebird consistency check (index bucket overfilled (205), file: btr.cpp line: 3493) Looks familiar. We had similar bugs in the past. This is a bug right? Can I help with more info? I'm afraid the only way to resolve it is to have a copy of your database (or backup) at hands. If you can make it available for download, please contact me off-list (firebird2 at yandex.ru). Size is not a problem. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 beta database recover problem: object has non-SQL security class defined
27.10.2014 12:30, Robbert-Jan wrote: While restoring a database with FB 3.0 beta 1 (backed-up with FB3 alpha 2), I get this error: action cancelled by trigger (3) to preserve data integrity object has non-SQL security class defined Can you provide us with this backup? Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 beta database recover problem: object has non-SQL security class defined
27.10.2014 13:34, Robbert-Jan wrote: Sure, I'm happy to. As long as I can put it somewhere privately (i.e. not on the internet) and you're willing to destroy it after analyzing/fixing. I will destroy it for sure. Where can I put it? Do you have FTP server in your company? The size of the fbk is 5 MB. Quite small, you may send it via email (firebird2 at yandex.ru), probably encrypted. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 beta database recover problem: object has non-SQL security class defined
27.10.2014 15:20, Robbert-Jan wrote: But do I have to create a issue in the tracker for this? I guess not, if it only applies to converting from alpha2 to beta1. I can now confirm this being an incompatibility in the backup format introduced between Alpha 2 and Beta 1. This affects packages only. So this is not a real bug. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 Beta 2 according to tracker
28.10.2014 00:09, Thomas Steinmaurer wrote: does the following reflect the real status quo on what needs to be done for Beta 2? http://tracker.firebirdsql.org/browse/CORE/fixforversion/10586 More or less. Some items from that list can be postponed and some minor tasks may be not in the list. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Multiple instances under windows (was Re: UsingFirebird 3, beta 1 - installer report)
27.10.2014 19:58, Paul Reeves wrote: What is - currently - the reason to keep supporting the cpl applet? Does it do anything more than just starting/stopping the service? It has always allowed switching the guardian on and off, as well as switching between running as an app or a service. My vote would be to say goodbye to the CPL applet. And maybe to the guardian as well. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] SysFunctions returning non-null value for null input
16.10.2014 14:55, Geoff Worboys wrote:
I've cut the problem down to the thing that's giving me
trouble: I want to return a non-null value when when the
input expression resolves to null. In the code below I'm
just trying to return a 0 (for the sake of the example).
This executes but still gives me a null result:
dsc* evlTestIt(Jrd::thread_db* tdbb, const SysFunction*,
Jrd::jrd_nod* args, Jrd::impure_value* impure)
{
fb_assert(args-nod_count == 1);
jrd_req* request = tdbb-getRequest();
dsc* value = EVL_expr(tdbb, args-nod_arg[0]);
if (request-req_flags req_null)
{
impure-vlu_desc.makeLong(0);
impure-vlu_desc.setNullable(false); // redundant??
request-req_flags = ~req_null;
return impure-vlu_desc;
}
return value;
}
Dmitry
--
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
Re: [Firebird-devel] Linux requirements for FB3
15.10.2014 18:50, Alex Peshkoff wrote: Distro kernel glibc Firebird3 ok Debian 6 2.6.32 2.11.2 no Debian 7 3.2.41 2.13yes RHEL-5 2.6.18 2.5 no RHEL-6 2.6.32 2.12no RHEL-7 3.102.17yes SLE113.0.76 2.11.3 no OpenSuse12.3 3.7.10 2.17yes OpenSuse13.1 3.11.6 2.18yes Fedora19 3.9.5 2.17yes Fedora20 3.11.10 2.18yes Mageia4 3.12.21 2.18yes Mageia5 3.15.2 2.19yes Ubuntu10.04 2.6.32 2.11.1 no Ubuntu12.04 3.2 2.15yes Ubuntu14.04 3.2 2.15yes Sounds reasonable. Maybe, although I'd prefer RHEL-6 to be supported as well. Dmitry -- 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
Re: [Firebird-devel] Linux requirements for FB3
15.10.2014 19:20, Alex Peshkoff wrote: In that case we will have to keep suing a hack with a shared posix mutex to avoid an old bug in a kernel fixed in 2.6.33 or 24 (do not remember exactly). Showed itself on CS when accessing same db remotely (i.e. as firebird user from OS POV) and embedded as root. This option is worse ;-) Dmitry -- 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
Re: [Firebird-devel] openCursors works different in embedded and remote
13.10.2014 19:23, Adriano dos Santos Fernandes wrote: Please look at test staticMessage2 at https://github.com/asfernandes/fbstuff/blob/master/src/test/v3api/StaticMessageTest.cpp The second openCursor tries to pass NULL to a not-NULL parameter. With embedded, the test works. With remote, openCursor returns a ResultSet and the exception happens only after a fetch. AFAIU, this is due to the lazy port protocol optimization, i.e. op_execute is deferred and sent together with the first op-fetch. So any error happening during isc_dsql_execute is returned only after calling isc_dsql_fetch. This is more or less as designed / expected side effect. Dmitry -- 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
Re: [Firebird-devel] wait vs nowait on meta data statements
03.10.2014 10:31, Martijn Tonies wrote: I noticed that with Classic 2.5, you can get “object in use” when trying to modify a stored procedure that’s been previously executed, see also: http://tracker.firebirdsql.org/browse/CORE-4016 When using “wait” on the transaction to save the procedure, instead of “nowait”, the problem goes away. Is it safe to always use “wait” on such transactions? Yes, it's safe. But I'd suggest to additionally specify the lock timeout for a DDL transaction to avoid unexpected lockups (e.g. if tables are dropped by the same DDL transaction). Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0.0.31348 - Weird domain metadata for newly created domain
03.10.2014 19:47, Adriano dos Santos Fernandes wrote: https://github.com/asfernandes/fbstuff/blob/master/src/test/v3api/StaticMessageTest.cpp Note the line string(output-description.str,output-description.length) for the SALES relation, which don't have a comment. Current (without a test for output-descriptionNull), it returns the value of the previous row. Before it was returning an empty string. This looks like my fault, it will be fixed within an hour. However, I'd say that the test is surely incorrect as it doesn't check for the NULL indicator. And the tool Thomas is using also looks buggy in this regard ;-) Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0.0.31348 - Weird domain metadata for newly created domain
03.10.2014 21:03, Martijn Tonies (Upscene Productions) wrote: You purposefully want to break existing applications because the Firebird client returns the data of the previous record. You don't get what's really happening. Firebird API (read: fbclient) represents every field with two parts: NULL indicator and field data. Ideally, nobody never should access the field data before checking the NULL indicator. It simply makes no sense. For NULL-indicated fields, there may be zeros, there may be garbage, there may be data of the previous record, or whatever. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0.0.31348 - Weird domain metadata for newly created domain
03.10.2014 21:20, Martijn Tonies (Upscene Productions) wrote: I get exactly what's happening. And it's clear to me -something- has changed in this regard, cause if it weren't, everything would be just fine. Then tell us how a properly written application (the one not ignoring the NULL indicator) could be affected by this change. Something working just fine does not mean it working correctly. P.S. This discussion is purely theoretical as compatibility has already been restored in the meantime. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0.0.31348 - Weird domain metadata for newly created domain
03.10.2014 21:37, Martijn Tonies (Upscene Productions) wrote: I never said a properly written application could be affected, I said something has clearly changed as existing applications suddenly return the wrong result. And I said that such existing applications are obviously buggy, but you disagreed that it's fbclient who's buggy. Damn, we're starting another circle ;-) Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] error on restore
02.10.2014 22:21, Roman Simakov wrote: Sorry for some kind of offtopic. What does it mean the last number in version? Is it synthetic build number? Yes, it's auto-generated. How can I understand what revision number was used to build it? Search by the build number in fb-checkins. Note that buildno is generated daily and multiple revisions could be created during that day. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] error on restore
02.10.2014 20:18, Frank Schlottmann-Gödde wrote: I'm getting gbak: ERROR:action cancelled by trigger (3) to preserve data integrity gbak: ERROR:object has non-SQL security class defined gbak:Exiting before completion due to errors when trying to restore a backup created by version LI-T3.0.0.31199 with version LI-T3.0.0.31348 any ideas? Are you sure about the former build number? IIRC, there was such a bug between revisions 31217 and 31230. And I don't remember anything else like that. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4568) Server may crash while disconnecting from the database under load
Server may crash while disconnecting from the database under load - Key: CORE-4568 URL: http://tracker.firebirdsql.org/browse/CORE-4568 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 Alpha 2, 3.0 Alpha 1 Environment: SC/CS only Reporter: Dmitry Yemanov If a page-level AST is delivered during the database disconnection, the server may crash. -- 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 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4564) Add per-table performance counters to the monitoring tables
Add per-table performance counters to the monitoring tables --- Key: CORE-4564 URL: http://tracker.firebirdsql.org/browse/CORE-4564 Project: Firebird Core Issue Type: Improvement Components: Engine Reporter: Dmitry Yemanov Currently, record level performance counters are available in MON$RECORD_STATS only globally (aggregating all affected tables). However, they are available at the per table basis in the trace output. It makes a lot of sense to report them per table in the monitoring tables too. -- 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 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] TCP Loopback fast path in Windows
26.09.2014 19:13, Leyne, Sean wrote: Localhost is not necessary for Classic and SuperClassic engine (I not sure of SuperServer, we don't use this mode), since local mode connections are supported XNET is not an option for Jaybird or .NET users. since the long-term path for Firebird is the deprecation of SuperServer You're surely misinformed. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] TCP Loopback fast path in Windows
26.09.2014 20:11, Leyne, Sean wrote: If v3 has the SMP improvements which are planned, why would we continue to support 3 engine versions? Classic and SuperClassic would have functionality which covers all use cases. v3 has the SMP improvements in *SuperServer*. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta release
24.09.2014 19:33, Tom Coleman wrote: We're almost in October and the FB3 beta release date still shows as August 31. SMB 3, memory management, etc., etc - all very interesting discussions but how are they leading to the highly-anticipated and much needed beta release? Beta release is expected the next week. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Beta release
24.09.2014 19:39, Dmitry Yemanov wrote: Beta release is expected the next week. Correction: Beta *code* is expected to be ready (i.e. tagged) the next week. The release itself will appear slightly later, after composing the docs and passing QA. Dmitry -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 memory manager
Nickolay, I implemented intermediate versions GC algorithm and tried to run some stress tests on Firebird 3 to check if I have broken something. The problem is that tests that I created were spending most of their time in memory manager. This is not healthy. Out of curiosity, what is the call sequence that leads to the memory manager load? AFAIU, this is not what should normally happen when processing records. Maybe post_verb / verb_cleanup? Dear Firebird engineers, why did you replace an algorithm which has O(log(n)) performance with an algorithm that has O(n) performance in such a performance-critical part of the engine? Maybe because you're speaking just about one case while there are other cases when the new memory manager was proven to be more efficient? I hope Alex will jump in with more details. I created a small query to demonstrate the effect of O(n) memory manager performance. === create table test7 (id integer); execute block as declare variable i integer = 1; begin while(i = 5000) do begin insert into test7(id) values(:i); i = i + 1; end end; commit; savepoint X; update test7 set id = id; delete from test7; === Last statement uses 3.5 Gb of memory in small blocks. Do you mean the undo log here? vct_records bitmap of 3.5GB? From quick review of new memory manager code I can see the following problems: 1) O(n) performance in small hunk allocation 2) O(n) performance in large hunk deallocation 3) Worst case allocation cost in large hunk allocation algorithm is bounded, but much worse than for older memory manager 4) Lots of memory waste in various scenarios, which is a security issue with mild risk. 5) Not all debug facilities have been preserved. Problem 1 and 2 can be relatively inexpensively fixed with existing code base. Are there volunteers? Problems 3 and 4 require going back to global best-fit allocation strategy, and thus re-design. Alternatively, I may fix Firebird 2.5 memory manager to have better performance in simple cases without compromising worst-case performance. This is rather easy. B-Tree can be replaced with specially designed array of pointers (see FastMM code, for example). Dmitry, do you want me to do this? I would warn against any quick decisions. Let's wait for Alex's comments first. My understanding is that Firebird project probably does not care about large installs and security, so it will continue using new memory manager as it is marginally faster in simple cases. Your understanding is surely incorrect. Good thing is that changing or replacing memory manager is very simple task for existing code base. I'd rather prefer the memory manager being replacable / pluggable at runtime. This is not about FB3 though. Dmitry -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
04.09.2014 19:25, Tom Coleman wrote: Speaking of the v3.0 release, who updates 3.0 Beta 1 release dates? Me. August 31 has come and gone: I know. Are there really just 5 unresolved issues delaying the beta release? Yes, around that number. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Coding style: one-line blocks
02.09.2014 19:05, Dimitry Sibiryakov wrote: if (some condition some other condition) hardly recognized line that doing something; This example violates the project coding style. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Coding style: one-line blocks
02.09.2014 18:35, Dimitry Sibiryakov wrote: When was decided that one-line blocks must not be enclosed with parentheses? It didn't change for the past few years: http://www.firebirdsql.org/en/coding-style/ http://geosoft.no/development/cppstyle.html 82. Single statement if-else, for or while statements can be written without brackets. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Coding style: one-line blocks
02.09.2014 21:27, Dimitry Sibiryakov wrote: if (temp.rpb_flags rpb_delta) temp.rpb_prior = data; doesn't look much better. Let me disagree. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 - Windows snapshot builds
02.09.2014 23:10, Gabor Boros wrote: Available snapshots date is august 27. Is it a known issue? Yes, Windows builds are broken. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 11:24, Alex Peshkoff wrote: That's nice - but what should happen with that special syntax when BLR follows DYN? Easy option - deprecate the command. A more clever one - not DROP (nullify) the source but set some flag to HIDE it instead. That flag would mean returning NULL instead of source blob for user requests, while still returning a proper source blob for internal requests. A compromise - ALTER ... HIDE SOURCE may be implemented via SET TO NULL in v3 and via the aforementioned trick starting with v4. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 19:58, Jim Starkey wrote: Anybody see any problems with it? I like neither DPB solution because it's DPB. It's not a connection string option, it's an API option. Surely not a problem for ISQL users that will support it out of the box. But most of existing user applications need to be recompiled to use the new option. Those devs who are too high level will have to wait until their underlying Firebird connectivity library is updated to support the new option. I don't call this user-friendly, sorry. IMHO, a DDL solution is much handier. And it's also implementable in a few hours. Relaxed write restriction for rdb$source is probably even easier to implement. And it doesn't require us to think about the forward compatible syntax. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 23:28, Dimitry Sibiryakov wrote: But it requires a quite complex condition, no? Not just if relation is system one, throw exception, but if relation is system one, but not this and that, throw exception. Complex condition is: relation is X and no other field but rdb$source is modified. We already have function in VIO doing such a check for other purposes. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 23:35, Dmitry Yemanov wrote: Complex condition is: relation is X and no other field but rdb$source is modified and the new value is NULL, of course. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
02.09.2014 00:22, James Starkey wrote: What possible user applications are going to be doing procedure and trigger definitions that require the source be omitted? Whatever user application that works with the database and executes metadata upgrade scripts itself, without invoking ISQL. And what syntax are you talking about? Option (1) from the list of solution being discussed, i.e. new DDL statement. The problem with write access to RDB$TRIGGERS and RDB$PROCEDURES (or whatever the correct names are) is that anybody with privilege can store crap, which is the reason they were to be made read-only except for the system. We may allow *only* setting rdb$source to NULL and *only* for SYSDBA / DBO, everything else will still be prohibited. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
02.09.2014 00:59, Dimitry Sibiryakov wrote: Complex condition is: relation is X and no other field but rdb$source is modified. We already have function in VIO doing such a check for other purposes. You are not going to simplify code, are you?.. Neither of the solutions being discussed simplifies the code, except removing of the system tables protection or leaving everything as is. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggerswill not work in FB 3
31.08.2014 22:11, Dimitry Sibiryakov wrote: To secure it from examining by users, no?.. This is the last reason for such a move. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
31.08.2014 15:51, Carlos H. Cantu wrote: We have a hack that many people uses for a long time, to make it more difficult to stole procedures/triggers source (more difficult, not impossible, since BLR can be decoded to source). They know it is not 100% safe, but so far it is the only way to avoid standard/common users (the ones who knows only how to connect to database and run select), to have access to the sources. What about unencrypted distributed databases? Should we care about hiding PSQL source also from SYSDBA / DBO? Are there real cases when it would be needed? 1) Create an official way to make the source null 2) Create a way to obfuscate the source 3) Create a way to store the source encrypted 4) Leave the rdb$procedures and rdb$triggers writable (or at list the source field). 5) Create special privilege for users to be able to retrieve the source code. See my question above. I would hate to support an object-level privilege that can be revoked from the object owner. And, given how our security works now, it won't work for SYSDBA anyway. 1, 4 and 5 seems to be the only solutions that could be done without delaying FB 3 release (core developers can confirm this). So far I tend voting for (1), using a special syntax. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4534) Invalid DB_KEY based retrievals when concatenation is involved
Invalid DB_KEY based retrievals when concatenation is involved -- Key: CORE-4534 URL: http://tracker.firebirdsql.org/browse/CORE-4534 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3, 2.1.6, 3.0 Alpha 2, 3.0 Alpha 1, 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5 Reporter: Dmitry Yemanov Priority: Minor Trivial demonstration: set plan; select * from rdb$database where rdb$db_key = x''; PLAN (RDB$DATABASE INDEX ()) -- OK select * from rdb$database where rdb$db_key || '' = x''; PLAN (RDB$DATABASE INDEX ()) -- unexpected, but it does not hurt select * from rdb$database where rdb$db_key || x'' = x''; PLAN (RDB$DATABASE INDEX ()) -- wrong select * from rdb$database where rdb$db_key || rdb$db_key = x''; PLAN (RDB$DATABASE INDEX ()) -- wrong Concatenation of DBKEYs is a special operation (used to combine individual DBKEYs for multi-table views) but the engine doesn't assume that user can also concatenate DBKEYs. Lack of proper checks may lead to invalid retrievals as shown above. -- 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 -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Unsigned integer TraNumber problem
26.08.2014 00:29, Nikolay Samofatov wrote: When you converted transaction number from SLONG to TraNumber (ULONG) you didn't take into account that LCK_query_data returns SLONG and uses signed integers internally. While there might be different solutions to this particular problem, I'm wondering whether it would be generally useful to have the lock data extended to 64-bit ints? Obviously, it would cost us four extra bytes per every lock request, but supposedly the size issue could be worked around if considered undesirable. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Unsigned integer TraNumber problem
26.08.2014 21:52, Jim Starkey wrote: As the original author of SLONG, ULONG, et al, might I suggest that you ditch them all in favor of the standard and size explicit int64_t, int32_t, etc.? When it was discussed the last time, some compilers (was it some ancient MSVC version?) didn't support these standard types. I hope we may forget about that these days. Also, while they deserve their place in ODS and API layers, I'm not so sure about the rest of the code. I'd rather prefer to have native ints there, with explicit casts to/from the size explicit types (and probably size validation) at the border layers. If somebody were to do a global edit to clean up artificial types, it would also be a good idea to flush the const correctness for objects in favor of clean, type safe, generally cast free code. I have no idea who came up with the idea of const correctness, but it violates the principal of encapsulation, the basis of object oriented programming. Here we're never going to agree. Const correctness does not violate encapsulation. There may be conflicts between object's contract (constness) and the underlying implementation details, but it's solvable natively in C++. Moreover, such conflicts are very rare in our codebase. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4530) DB_KEY based join of two tables may be ineffective
DB_KEY based join of two tables may be ineffective -- Key: CORE-4530 URL: http://tracker.firebirdsql.org/browse/CORE-4530 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3, 3.0 Alpha 2 Reporter: Dmitry Yemanov Simplified test case: set planonly; recreate table t (id int primary key); commit; select count(*) from (select id, rdb$db_key k from t a order by id) x left join t z on x.k = z.rdb$db_key -- (*) PLAN JOIN (X A ORDER RDB$PRIMARY4, Z NATURAL) vs select count(*) from (select id, rdb$db_key k from t a order by id) x left join t z on z.rdb$db_key = x.k -- (*) PLAN JOIN (X A ORDER RDB$PRIMARY4, Z INDEX ()) i.e. order of expressions in the join condition affects the generated plan and thus performance. -- 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 -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Tackling CORE-4526 (OFFSET FETCH)
22.08.2014 18:54, Mark Rotteveel wrote: Are there any objections if I try to come up with a patch to add OFFSET and FETCH to the select syntax (CORE-4526)? Feel free. Dmitry -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Error messages how-to
12.08.2014 18:03, Mark Rotteveel wrote: Doesn't this miss a add specific standard (or vendor-specific) SQL state somewhere? It's hidden inside item (3) ;-) Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] So, What's wrong with IBPP?
11.08.2014 13:45, Mark Rotteveel wrote: To illustrate: you seem (?) to be speaking from the perspective of a target audience who use the interface in application development, and where you don't want to deal with all the nitty gritty low-level details, here IBPP is probably a good fit (but as I haven't used it, I can't say). However speaking as the developer of Jaybird, I don't want an API that will perform too many conversions or work that I will need to redo to make it work the same or similar as the wire protocol implementation, and to make it work within the rules established by JDBC. In that case an API that does too much heavy lifting is actually a hindrance (or at minimum a potential performance bottleneck). These are already two - somewhat - conflicting needs. Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). A higher level API (like IBPP) to do some of the heavy lifting for application development is a nice to have. And as you say: it already exists: IBPP. This is exactly the developer's position, at least how I understand it myself ;-) IBPP is C++ only and too high-level. The FB API should be lower-level and language-independent. The legacy ISC API mostly serves this goal (although it's not that low-level really, some hidden conversions/movements happen there), but it's showing its age. So we attempted to offer a modern replacement with the v3 OO API. IBPP can still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would act the same for Delphi, etc. They just need to be ported to the new core API (whatever it will be). Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 18:18, Jim Starkey wrote: Since plugins pretty much need to be compiled with the same compiler as the engine Very questionable requirement. I can easily expect plugins written in Delphi. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 22:08, Adriano dos Santos Fernandes wrote: But an (client) application wants to generate exception when accessing the API, and we do not know in advance what's the good classes for each project. And we'll never know. This is not our business, IMO. Some may use like Firebird, an Exception not inherited, others wants std::exception, a Qt-based project would want another one... This is for the higher level wrappers to care about. For example, IBPP throws its own exceptions. Firebird driver for Qt may have its own exceptions. And so on. We either forget about exceptions completely, or throw some partially abstract class (thus forcing users to implement the exception before being able to compile), or maybe go for the policies you described. That said, I'd rather resolve the other issues first. Even a no-exception API may be good enough for the time being, we can offer something better later. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 07:09, Adriano dos Santos Fernandes wrote: I did some tests and detected that FPC class with or without virtual methods has a pointer in its start. From what I've seen on the web, there should be three pointers there. But maybe it depends on the compiler settings or other reasons (like for RTTI and multiple inheritence in gcc). Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 12:34, Reinier Olislagers wrote: Do I understand correctly that the existing FB 2.5 C API will therefore remain supported Correct. and updated with new features for each FB release? Not necessarily correct. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 13:48, Dimitry Sibiryakov wrote: It is an open project, no?.. It is. But open unmanaged. When C API missed a new feature that I could use, I created a patch, submitted it to the project and it may be either accepted or rejected. Because you may disappear tomorrow but the project will have to maintain your patch till the end of life. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 13:55, Reinier Olislagers wrote: However, apparently FB devs don't think it's important to keep it in sync with the C++ interface - even if third parties could submit patches for that. So in effect, new FB (features) will not be compatible with any language that does not have C++ support. So far we're trying to find a compromise. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 14:09, Dimitry Sibiryakov wrote: Whole project is inherited, remember?.. You have to maintain code written by Jim, Mike, Arno, Nikolay and others, so why not mine?.. Everything depends on the patch. There's a difference between *can* be accepted and *will* be accepted. If you come with the patch restoring old ODS support in v3, it will be rejected simply because the active project members don't want to spend their time supporting that. It was discussed and agreed on. Whatever we agree on regarding the legacy API, we cannot stop maintaining it within its current boundaries. But whether it must be extended to accomodate all the new features is a subject of discussion, primarily depending on conclusions derived from this topic. Multiple separately maintainted APIs may be the same pain as with ODS. I'm not against the legacy API, it is all about the required efforts. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 14:10, Jim Starkey wrote: It is a fool's errand to try to build a OO interface that is call compatible across a wide range of OO languages. If anyone is in doubt, look at Objective-C and weep. If this is found being impossible (I'm not deeply involved, so I don't have a strongly argumented opinion yet), then we have [at least] three questions to answer: 1) Do we keep the existing OO Y-valve API for internal purposes? E.g. for engine plugins or for remote-engine calls. The same issues apply but we can expect virtually zero practical risks here (I doubt we'll be writing some parts of the server in FreePacal or Lua). Maybe some interfaces could be simplified in this case. 2) Do we offer the existing OO Y-valve API to other C++ users? It has to be public and limitations (including binding issues) have to be documented. 3) Do we keep using the legacy ISC API as the plain C wrapper for non-C++ users or invent a better replacement? Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
10.08.2014 19:45, Dimitry Sibiryakov wrote: When will you start to separate application API and plugin API?.. UDRs must use a regular application API for callbacks into the engine, this is a design requirement. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
09.08.2014 21:19, Dimitry Sibiryakov wrote: It has to be channeled to benefit current and prospective users. Current users don't care about API because they don't use it. They use all kind of envelopes which are already OO-oriented, tested by years and well documented. Future users also will use them instead of API because new API has no such features. Here we mostly speak about FB API users, not FB users in general (they really don't care). None of the connectivity layer developers will be using the new API if it does not provide them with some new features. In FB3, there are very few of them, but with FB4 the situation may start looking differently. There's also a different aspect, much more important IMO. How hard is to develop a new connectivity layer (for FreePascal / Node.js / JavaScript / Haskell / whatever) using our API. The easier it is, the more prospective users we can get. The SQLDA stuff was sometimes described by newcomers as PITA to deal with. If the new API, be it OO or plain C, can be more user-friendly (in terms of usability and extendability), then it wins hands down. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] dtype_packed
05.08.2014 12:19, Mark Rotteveel wrote: Not an authorative answer, but it seems that dtype_packed is also known in COBOL (and SAP) for a BCD (binary coded decimal). If that also applies to Firebird, I am not sure. dtype_packed really seems to be a packed decimal, however it's not used by Firebird since day one. Kinda historical artifact. Dmitry -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] SVN: firebird:[59943] firebird/trunk/src/yvalve/why.cpp
03.08.2014 18:29, Dimitry Sibiryakov wrote: Commented out the annoying (thus supposedly wrong?) assertion. Without this assert following code will crash with segfault on using offsets array. If this assert is activated on queries without output parameters, it should be changed to fb_assert(count == 0 || offsets), not just commented out. I've just left it to the author to fix. I couldn't run tpcc with this assert activated. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] DDL permissions
01.08.2014 18:55, Simonov Denis wrote:
SQL insert into RDB$EXCEPTIONS(RDB$EXCEPTION_NAME) VALUES ('E1');
At the first glance, I don't see why it cannot be prohibited. But I see
from the code that many system tables are still unprotected from user
inserts. Maybe Claudio still has some pending commits on this subject.
Or maybe there are some hidden issues I don't see.
Dmitry
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] COMMENT ON docs
28.07.2014 20:57, Dalton Calford wrote: Has any work been performed on implementing schema/synonyms/larger object identifiers? Nope, as far as I'm aware of. It was proposed for v4 but so far I don't see anybody jumping in with lots of interest... Dmitry -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] COMMENT ON docs
28.07.2014 22:20, Dalton Calford wrote: So, let me understand this. (a) the plan is to block/remove access to the system tables Wrong, at least in the short term. Currently we're trying to block *write* access to the system tables, no more than that. (b) functionality will not be added until it is in the sql standard, even though we are not implementing everything that is currently in that standard as some of it does not make sense or no one wants to do it. Non-standard functionality is added if we agree that it does make sense. (c) the loss of functionality such as blocking sysdba access or displaying comments will not be compensated with extensions to the language. You may live without SYSDBA in FB3. And displaying comments is available with either SELECT or SHOW (latter is isql only). What would prevent a show command to be added to the language? Show comments on Show ddl for Show dependencies on ... etc. IMHO, it's counternatural to SQL. A non-SELECT/non-EXECUTE command that returns what? A blob? What is the name of the output parameter, COMMENT or what? How should it be described in API so that thousands of existing apps understood it? Interbase became such a good system by NOT following the standard but by adding flexibility and features to the baseline product. I seem to recall that interbase was one of the first if not the first to support blobs which where definitely not part of the standard at the time. I'm afraid there were no standard at all those dark times. There are some security enhancements that red soft has that would be wonderful in the core product, but, we don't see them yet. Some of them are already in the core. May you enumerate others that you urgently need? I wonder if redsoft is still actively developed and supports schema? Yes, it's actively developed. No, it doesn't support schemas. I don't think you can have/use schemas without recompiling all those thousands of existing applications and/or their underlying database connectivity libraries. Dmitry -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
25.07.2014 18:43, Jim Starkey wrote: If an interface is incompatible, existing applications have to be recoded. If they need to be recoded, there isn't any real purpose to retaining an interface style. At the moment the new API and the legacy one are mostly compatible, actually the legacy API is now a thin wrapper over the new API. The major difference is that we introduced an explicit Cursor/ResultSet interface and it somewhat changed the legacy named cursor semantics (which is fixable, I believe, we just need to find the best solution). Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] setCursorName in IResultSet rather than IStatement
24.07.2014 14:37, Dimitry Sibiryakov wrote: In new API you can simply deprecate using named cursors. They are almost useless anyway. And also deprecate WHERE CURRENT OF in DSQL for being useless? Just because you don't use it? Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] setCursorName in IResultSet rather than IStatement
24.07.2014 14:54, Dimitry Sibiryakov wrote: Does it work without FOR UPDATE in SELECT now? I haven't tried. Did it work before? Has FOR UPDATE clause stopped killing network peformance? Not everybody is working with slow networks. Using RDB$DB_KEY for DML has the same effect as WHERE CURRENT OF Nope, it's a bit slower. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] setCursorName in IResultSet rather than IStatement
24.07.2014 15:14, Dimitry Sibiryakov wrote: I haven't tried. Did it work before? No. And this is correct. Not everybody is working with slow networks. Any network is slow for transferring one record per fetch. Embedded server shows this problem well. (Every SELECT in it works in non-buffered mode.) Embedded is not affected by the FOR UPDATE clause. And yes, it's used in time-critical applications. Nope, it's a bit slower. Why? What's the difference? RDB$DBKEY requires a record fetch/lookup (costs at least two pages fetches plus decompression). WHERE CURRENT OF deals with the already fetched record which resides in memory. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problems with the Firebird 3 API
21.07.2014 18:04, Alex Peshkoff wrote: Ahh - it's related with multiple inheritance and rtti. Luckily we do not use both in interfaces. Just for clarity - besides that, we must neither use virtual destructors nor overloaded methods to guarantee the stable vtable layout. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problems with the Firebird 3 API
22.07.2014 14:54, Alex Peshkoff wrote: Not sure how does presence of overloaded methods affect stability of vtable layout, but agree that we should better avoid them in public interfaces. Even if you put an overloaded method at the end of the interface, its vtable entry will be placed in the middle (alongside with its counterpart) by the compiler, thus breaking the ABI compatibility. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 build broken with gcc under Linux
22.07.2014 14:44, Dimitry Sibiryakov wrote: Instead of fixing handling 32 bits internally without any bounds checking In general, I don't like platform dependent datatypes in the public API, hence my objections to size_t. (*) The problems, as I see them, are: 1) It may complicate client programs if their compiler misses a 100% analogue. One might need to introduce conditional compilation etc. 2) If the underlying implementation cannot deal with 64-bits-long objects, it (1) requires bounds checking and (2) partially defeats the whole purpose of interface as a contract (i.e. interface promises something it cannot handle). 3) If the underlying implementation can deal with 64-bits-long objects, the situation starts looking better. However, this is commonly *not* the case for Firebird (maybe Trace API is an exception here, I don't know). (*) I was objecting to using plain ints there for the same reason. We're just lucky to not supporting Itanium or some other platform with 64-bit ints. One day this issue will strike back but lots of wrongly defined headers will already be distributed around the world. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problems with the Firebird 3 API
22.07.2014 15:31, Jim Starkey wrote: Why do you care? If the C++ interface (pure virtual) is expected to be used outside the Firebird project (by other C++ applications) or even by different Firebird versions (e.g. newer server loading the older engine), then we must care. You cannot extend the interface by an overloaded function and expect its binary compatibility with the prior interface version. If the only public API is a [machine-generated] language-neutral plain C stuff, then I don't care. This is not what we have at hands though. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 build broken with gcc under Linux
21.07.2014 13:13, Alex Peshkoff wrote: We were using system size_t until Nickolay had committed FB_SIZE_T a few days ago in attempt to avoid warnings. The bad thing is that it wasnt't discussed. Not too late to begin discussion now. I would sooner agree with the change and Nickolay's arguments to do it (present in comment in h-file) no matter of the fact that it would be good idea to check builds better after such changes. Nickolay's comment is absolutely correct. However: 1) The root of the warnings issue was that size_t actively used in our classes library was often compared and/or assigned to/from shorter SLONG/ULONG variables. And the compiler was correctly showing where our code is not ready for big (4GB) objects. Making both ULONG and FB_SIZE_T the same [smaller] size is an obvious solution, but strictly speaking it just hides the issue instead of fixing it. If one day we want to support objects bigger than 4GB, one would need to enable FB_USE_SIZE_T and start from scratch. This is not really an objection as long as FB_USE_SIZE_T is preserved, rather just a comment of mine. 2) Also, it introduces more artificial datatypes than we had. I remember we were dicussing an intention to minimize artificial datatypes in favor of native compiler ones in all places that are not ODS/API related. New API already does that. So I see the patch as a step backward in this regard. And I really hate seeing/writing typedefs in such trivial places like counter-based loops. 3) If size_t was used in any public interface, then IMHO it was a mistake. Looking at the new API, unsigned int should be used instead. IMO, FB_SIZE_T must be a private typedef and thus should be moved from types_pub.h to fb_types.h. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problems with the Firebird 3 API
21.07.2014 16:32, Alex Peshkoff wrote:
First of all - formal definition of API is certainly not a set of C++
classes. Each firebird interface is a single pointer, pointing to the
table of virtual functions that are contained in this interface. First
parameter of each function is always a pointer to an interface itself.
This definition in plain english may be rewritten in C:
struct ISample
{
struct VTable
{
void functionOne(ISample* this, Type1 par1, Type2 par2, /*
other parameters */);
void functionTwo(ISample* this, TypeA parA, TypeB parB, /*
other parameters */);
/* other functions ... */
};
VTable* vTable;
};
Such definition of pure virtual interface should work and be correct for
any working C compiler.
[snip]
in C++ we get exactly same binary layout for any known to us C++ compiler.
Is this really so? This is why I'm asking:
https://gcc.gnu.org/ml/gcc-help/2003-11/msg00257.html
http://stackoverflow.com/questions/5712808/understanding-the-vtable-entries
i.e. GCC has a different vtable layout and moreover it's version-dependent.
As for Free Pascal, they also reserve 12 bytes at the beginning of the
vtable, hence the compatibility issue.
Dmitry
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 build broken with gcc under Linux
21.07.2014 18:16, Alex Peshkoff wrote: I think we should wait for Nickolay's mind before doing some big changes. I don't propose any big changes now, so far we're just discussing. Maybe there will be other opinions posted here. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problems with the Firebird 3 API
21.07.2014 18:04, Alex Peshkoff wrote: Ahh - it's related with multiple inheritance and rtti. Luckily we do not use both in interfaces. I didn't try your test app, but I can confirm the expected vtable layout (at least for IProvider) in the debugger (for gcc 4.8.2). As for Free Pascal, they also reserve 12 bytes at the beginning of the vtable, hence the compatibility issue. 12 byte? On 64-bit system? They are crazy! Probably 12 bytes were about 32-bits, i.e. three additional pointers. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3 build broken with gcc under Linux
19.07.2014 14:14, Roman Simakov wrote: IMO FB must use system size_t. We were using system size_t until Nickolay had committed FB_SIZE_T a few days ago in attempt to avoid warnings. The bad thing is that it wasnt't discussed. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] DDL permissions
17.07.2014 12:32, Simonov Denis wrote: After adding restrictions on DDL statements, I can not start initialized security3.fdb GSEC add sysdba -pw masterkey An error occurred while attempting to add the user. unsuccessful metadata update CREATE TABLE PLG$SRP failed There is no privilege for this operation GSEC Two workarounds are possible: (1) gsec -user sysdba -pass masterkey GSEC add sysdba -pw masterkey or (2) isql -user sysdba employee SQL create user sysdba password 'masterkey'; Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] C++ and the API
16.07.2014 12:15, Dimitry Sibiryakov wrote: This criticism is valid not for API itself, but mostly for its internal implementation. API is fine, code under the hood is inadequate. Once again, you don't count the message based API being a public API. Most of 16 bits limitation belongs to the Message API which is not used now. It's no longer used by the DSQL API, but it's still used directly by at least GBAK and GPRE. I suspect it would be much easier porting them to the new OO API (preserving the message based architecture) rather than rewriting them from scratch to use the DSQL API. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] C++ and the API
15.07.2014 17:49, Dimitry Sibiryakov wrote: It even refuses to open (leave alone absence of links from official www server). Surprise, but the link is from the official www server. Dmitry -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] The Firebird 3 API and programming language independence
13.07.2014 18:36, Dimitry Sibiryakov wrote: http://sourceforge.net/projects/uib/ And the module he supposedly refers to is: https://sourceforge.net/p/uib/code/HEAD/tree/trunk/source/uibfblib.pas Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
