Menu
▾
▴
firebird-devel
|
From: Dmitry Y. <fir...@ya...> - 2014-04-24 10:19:36
|
All, We're getting closer to the v3.0 feature freeze which is going to happen this summer. Everything roadmapped for v3 but not implemented before the deadline will be postponed. The next-after-v3 release is likely to incorporate most of the postponed features, but there may be new features as well. So it makes sense to start discussing what could and should be done in the next version(s). We have a few months to collect the proposals, discuss technical details and make estimates about the required efforts. This message is the invitation to both project members and users who closely follow the development. If you want to discuss something for potentially including into the new version(s), feel free to do that in separate threads. Please be prepared to protect your opinion and discuss the details, simple votes "I like feature X" don't count. A tracker ticket for the feature request is appreciated, please add its URL to your post. Just for the reference, the top-voted tickets can be found here: http://tracker.firebirdsql.org/browse/CORE?report=com.atlassian.jira.plugin.system.project:popularissues-panel The ongoing results of the planning stage will be published on our website and scheduled for the next version(s) by the project admins. Dmitry |
|
From: Simonov D. <sim...@li...> - 2014-04-28 12:14:42
|
My list is as follows. optimizer 1. Enable use MERGE / HASH JOIN for OUTER JOINs 2. Performing EXISTS / IN SEMI JOIN as including using MERGE / HASH, and NESTED LOOP using index 3. HASH aggregation Add to an existing method using sorting 4. Conditional INDEX ONLY SCAN as in Postgresql (dimitr said that it is possible to ODS 12) PSQL and SQL 1. Add the ability to specify offer framing for window functions http://tracker.firebirdsql.org/browse/CORE-3647 2. Add JAVA, .NET PROCEDURE and FUNCTION (not just C++) 3. ROW VALUE CONSTRUCTOR http://tracker.firebirdsql.org/browse/CORE-3880 4. PACKAGEs Add to constants and variables http://tracker.firebirdsql.org/browse/CORE-670 5. Add the ability to write your own aggregate functions http://tracker.firebirdsql.org/browse/CORE-1326 Common Features 1. Bidirectional indices (one index for ASC and DESC) 2. Standby can be based on nbackup http://tracker.firebirdsql.org/browse/CORE-2990 3. Built as a plug -row replication . The standard delivery enable replication between servers firebird. For other servers, you can write your own plugin. Meaning plug-in capability to intercept changes from any table and write them in a log ( with options for filtering tables) , and then transmits a service already changed in another database. Create a bunch of triggers to support replication is not the nicest way. http://tracker.firebirdsql.org/browse/CORE-2021 |
|
From: Dimitry S. <sd...@ib...> - 2014-04-28 12:33:23
|
28.04.2014 14:14, Simonov Denis wrote: > 3. Built as a plug -row replication . The standard delivery enable > replication between servers firebird. For other servers, you can write > your own plugin. I'm sleeping on it. > Create a bunch of triggers to support replication is not the nicest way. May be it is not nicest, but it also has advantages. -- WBR, SD. |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-28 14:50:13
|
28.04.2014 16:14, Simonov Denis wrote: > > My list is as follows. Thanks, but I seemed to explicitly state that plain wishlists don't count. Choose top five from your list, start separate thread per feature and argue why we should prefer these features over other ones. Dmitry |
|
From: Dalton C. <dal...@gm...> - 2014-04-28 15:49:03
|
I will begin with the list of items I would like to see implemented. Object Names of at least 64 bytes - Core 749 Schemas plus associated objects (synonyms etc) - Core 738 Firebird native for Android - Core 3885 Scheduler for Firebird - Core 1613 Database Links - Core 776 The first two items are so obvious, I can not think of anyone who would argue against them. I will defend those items, but won't in this particular email. Android and iOS native clients if not native servers, are extremely important given the market growth in those areas and the lack of a good solid database engine to work with. A scheduler for firebird would totally eliminate my own use of custom applications tied to database events/time events. I am sure that I am not the only person who has had to develop around the lack of a scheduler/event handler in firebird that runs in its own transaction/user space. Database links, which would require the Object names and schema support, would allow for developers to implement many features manually that are now in the wish list catagory. For example, you could put each schema into a remote server/database, allowing for basic clustering (before you jump on me, I know it is more complex than that, I have implemented alot of this via other code). You could easily develop your own replication systems. One feature change, could be used to implement so many other requested features as well as providing a tool so that developers/users could come up with new ways of using firebird that are not even imagined now. best regards Dalton On 28 April 2014 10:50, Dmitry Yemanov <fir...@ya...> wrote: > 28.04.2014 16:14, Simonov Denis wrote: > > > > My list is as follows. > > Thanks, but I seemed to explicitly state that plain wishlists don't > count. Choose top five from your list, start separate thread per feature > and argue why we should prefer these features over other ones. > > > Dmitry > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-28 17:59:15
|
28.04.2014 19:48, Dalton Calford wrote: > Android and iOS native clients if not native servers, are extremely > important given the market growth in those areas and the lack of a good > solid database engine to work with. Isn't sqlite solid enough? ;-) At least for the tasks a tablet can run. > A scheduler for firebird would totally eliminate my own use of custom > applications tied to database events/time events. Architecturally, Firebird database is not active without user connections. This slightly changes with the LINGER support, but not so much. So the question is who should be waiting for the timer events when nobody is connected. And if it should be the server's (not the engine's) feature, then what to do with the embedded setup? > Database links, which would require the Object names and schema support I fail to see how they would require one or another. Or maybe I just see database links completely differently. > For example, you could put each schema into a remote server/database Your imagination surely takes a lead over mine. I've never thought of the database links this way. And I'm not really sure I want to. Dmitry |
|
From: Dalton C. <dal...@gm...> - 2014-04-28 19:31:27
|
Hi Dmitry, On 28 April 2014 13:59, Dmitry Yemanov <fir...@ya...> wrote: > Isn't sqlite solid enough? ;-) At least for the tasks a tablet can run. > > Today's tablets blow away the server systems I used to run interbase on. In some cases, they are more powerful than some realtime firebird servers we have - don't question the power of cell phones and tablets, they will amaze you. > > A scheduler for firebird would totally eliminate my own use of custom > > applications tied to database events/time events. > > Architecturally, Firebird database is not active without user > connections. This slightly changes with the LINGER support, but not so > much. So the question is who should be waiting for the timer events when > nobody is connected. And if it should be the server's (not the engine's) > feature, then what to do with the embedded setup? > > You should be able to define a database daemon/virtual user that runs as a separate transaction space. If defined and active, the database would always be running. > > Database links, which would require the Object names and schema support > > I fail to see how they would require one or another. Or maybe I just see > database links completely differently. > Well, picture schema that can contain schema ie database.schema_level1.schema_level2.schema_leveln.database_object. In this case, you could attach the root of a remote database as a branch/schema to the current database. > > > For example, you could put each schema into a remote server/database > > Your imagination surely takes a lead over mine. I've never thought of > the database links this way. And I'm not really sure I want to. > > The key here is, don't limit the end user/developer, give the tools and let them shoot themselves in the foot. Firebird and Interbase before it, was all about the flexibility/power in an easy to use package. But, it always assumed that the users where intelligent and capable, instead of trying to make the simplest system for the lowest common denominator. ;) |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-29 07:59:06
|
28.04.2014 23:31, Dalton Calford wrote: > > Architecturally, Firebird database is not active without user > connections. This slightly changes with the LINGER support, but not so > much. So the question is who should be waiting for the timer events when > nobody is connected. And if it should be the server's (not the engine's) > feature, then what to do with the embedded setup? > > You should be able to define a database daemon/virtual user that runs as > a separate transaction space. If defined and active, the database > would always be running. Who should initiate that dedicated listener deamon/user after a server restart? Should the server attach all the databases itself to check whether one needs a startup? What about databases unknown to the server (not present in databases.conf)? > Well, picture schema that can contain schema ie > database.schema_level1.schema_level2.schema_leveln.database_object. I seriously doubt that hierarhical schemas is a good thing (tm). What does the SQL specification says in this regard? Schema is a standard feature, it makes a lot of sense to follow the standard here. > In this case, you could attach the root of a remote database as a > branch/schema to the current database. This is completely different feature request, IMO. And honestly, I don't like auto-mounting of remote objects. Imagine a remote database inaccessible. Should we forbid connections to our local database? Or invalidate only the remote schema? Or invalidate also all local PSQL objects referencing the unavailable schema? Dmitry |
|
From: Alex <pes...@ma...> - 2014-04-29 06:59:38
|
On 04/28/2014 09:59 PM, Dmitry Yemanov wrote: >> A scheduler for firebird would totally eliminate my own use of custom >> applications tied to database events/time events. > Architecturally, Firebird database is not active without user > connections. This slightly changes with the LINGER support, but not so > much. So the question is who should be waiting for the timer events when > nobody is connected. And if it should be the server's (not the engine's) > feature, then what to do with the embedded setup? We may use OS native scheduler as timer with firebird implementing SQL interface to control it. This will work for any kind of setup, including embedded. The disadvantages are that timers get out of transaction control and we will need 2 absolutely different implementations - posix and windows. |
|
From: Claudio V. C. <cv...@us...> - 2014-04-28 21:20:18
|
> -----Original Message----- > From: Dalton Calford [mailto:dal...@gm...] > Sent: Lunes, 28 de Abril de 2014 11:49 > > For example, you could put each schema into a remote > server/database, allowing for basic clustering (before you > jump on me, I know it is more complex than that, I have > implemented alot of this via other code). Then you'll want to give your feature another name, not schema. Schemas are logical partitions of a physical db, not physical scattering of a db file(s) across different servers. C. |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-28 18:31:09
|
28.04.2014 16:14, Simonov Denis wrote: > > optimizer > 1. Enable use MERGE / HASH JOIN for OUTER JOINs > 2. Performing EXISTS / IN SEMI JOIN as including using MERGE / HASH, and > NESTED LOOP using index > 3. HASH aggregation Add to an existing method using sorting I don't think the optimizer algorithms should become the planning goals. They evolve from version to version anyway. But your point is taken, thanks. > 4. Conditional INDEX ONLY SCAN as in Postgresql (dimitr said that it is > possible to ODS 12) Theoretically possible, but only in some rare cases. There are other issues preventing it from working (now). > 2. Add JAVA, .NET PROCEDURE and FUNCTION (not just C++) You can do it in v3 as soon as someone writes the required interfacing plugins (external engines). Volunteers anyone? > 2. Standby can be based on nbackup > http://tracker.firebirdsql.org/browse/CORE-2990 And it can be based on other solutions too. Why do you think this one is the best? Dmitry |
|
From: Adriano d. S. F. <adr...@gm...> - 2014-04-28 18:36:30
|
On 28/04/2014 15:30, Dmitry Yemanov wrote: >> 2. Add JAVA, .NET PROCEDURE and FUNCTION (not just C++) > You can do it in v3 as soon as someone writes the required interfacing > plugins (external engines). Volunteers anyone? > Java was done, but due to everything (Jaybird and Firebird APIs) being changed, it's not a easy task to recreate it. Also I have a big conceptual problem with character sets when running C++ inside the database. Things are not good yet. Adriano |
|
From: Mark R. <ma...@la...> - 2014-04-29 07:55:37
|
On Mon, 28 Apr 2014 15:36:45 -0300, Adriano dos Santos Fernandes <adr...@gm...> wrote: > On 28/04/2014 15:30, Dmitry Yemanov wrote: >>> 2. Add JAVA, .NET PROCEDURE and FUNCTION (not just C++) >> You can do it in v3 as soon as someone writes the required interfacing >> plugins (external engines). Volunteers anyone? >> > Java was done, but due to everything (Jaybird and Firebird APIs) being > changed, it's not a easy task to recreate it. If it is redone, I think it is better if it is something that depends on Jaybird instead of as a fork of Jaybird. I think this requires a number of things within Jaybird: * New protocol implementation/API of Jaybird needs to be finished (or at least: finished enough that it is not implementing against a moving target), * (maybe) The current dependency in Jaybird on the Connector API needs to be moved from the core of Jaybird to an outer layer (so it is only needed for the Resource Adapter implementation) to simplify basic JDBC use and minimize dependencies, * Time (and funding) to do this. Mark |
|
From: Simonov D. <sim...@li...> - 2014-04-29 05:45:55
|
Dmitry Yemanov wrote: >> 2. Standby can be based on nbackup >> http://tracker.firebirdsql.org/browse/CORE-2990 > > And it can be based on other solutions too. Why do you think this one is > the best? > I am not sure that is the best way to implement, but probably the easiest. Other ways could become one of the replication mode (which is now in general rudiments not) or roll forward on the basis of the transaction log, which is also not available. In any case, even if in the future receive a mechanism to ensure the same opportunities that would not be worse. |
|
From: Simonov D. <sim...@li...> - 2014-04-29 06:01:51
|
Simonov Denis wrote: > > My list is as follows. > still would like to have implemented something safe from what it was postponed FB3: Groups of users and rights http://tracker.firebirdsql.org/browse/CORE-751 Ability to grant role to another role http://tracker.firebirdsql.org/browse/CORE-1815 And of course a complete ban on direct modification of system tables |
|
From: Mark R. <ma...@la...> - 2014-04-29 08:09:32
|
On Tue, 29 Apr 2014 11:58:57 +0400, Dmitry Yemanov <fir...@ya...> wrote: > Who should initiate that dedicated listener deamon/user after a server > restart? Should the server attach all the databases itself to check > whether one needs a startup? What about databases unknown to the server > (not present in databases.conf)? If you look at SQL Server, there jobs themselves are not defined for a specific database (although they may depend on one or more databases). AFAIK they are stored in the master database. Execution requires an Agent service to be running. Mark |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-29 08:24:08
|
29.04.2014 12:09, Mark Rotteveel wrote: > If you look at SQL Server, there jobs themselves are not defined for a > specific database (although they may depend on one or more databases). > AFAIK they are stored in the master database. Execution requires an Agent > service to be running. We neither have a master database, nor an agent service, nor database links to access user dbs from a master one (or any other solution to this issue). Shouldn't we think about something more realistic? Or at least postpone scheduled tasks until we have a proper foundation built? Dmitry |
|
From: Leyne, S. <Se...@br...> - 2014-05-01 14:27:13
|
> > If you look at SQL Server, there jobs themselves are not defined for a > > specific database (although they may depend on one or more databases). > > AFAIK they are stored in the master database. Execution requires an > > Agent service to be running. > > We neither have a master database, nor an agent service, nor database links > to access user dbs from a master one (or any other solution to this issue). > Shouldn't we think about something more realistic? Or at least postpone > scheduled tasks until we have a proper foundation built? I certainly think so. People are confusing the features which are available from the heavy weight SQL engine installs (I mean install/footprint size), and thinking that the "engine" implements the scheduler features. As you correctly pointed out, they do not. There are supporting elements/components/elements which are responsible for that. Certainly none that easily map to an embedded simple DLL deployment model. Sean |
|
From: Carlos H. C. <li...@wa...> - 2014-04-29 12:32:44
|
DY> 29.04.2014 12:09, Mark Rotteveel wrote: >> If you look at SQL Server, there jobs themselves are not defined for a >> specific database (although they may depend on one or more databases). >> AFAIK they are stored in the master database. Execution requires an Agent >> service to be running. DY> We neither have a master database, nor an agent service, nor database DY> links to access user dbs from a master one (or any other solution to DY> this issue). Shouldn't we think about something more realistic? Or at DY> least postpone scheduled tasks until we have a proper foundation built? DY> Dmitry I'm considering that "master database" would be used only to store the jobs information. A client/daemon would read it, create all the schedules and run the tasks at desired time (use of OS scheduler is an option too). Such "master database" (better call it jobs/tasks/scheduler database?) can be created and distributed with new installations (like the security2.fdb already is). If you don't worry about mixing things a bit, maybe even security2.fdb could be enhanced to store jobs data, avoiding the need to create a new pre-installed database. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br |
|
From: Mark R. <ma...@la...> - 2014-04-29 13:04:52
|
On 29-4-2014 14:45, Alex Peshkoff wrote: > We do not have single fixed security database in FB3. Therefore us of it > as jobs storage is not good choice. Adding new one looks better to me. > But once again embedded problem is here - up to the fact that embedded > user may have no rights to start daemons. IMHO an embedded instance shouldn't do that. Only a normal server install, if necessary through a separate daemon process (/windows service) that is started separately. -- Mark Rotteveel |
|
From: Carlos H. C. <li...@wa...> - 2014-04-29 13:28:06
|
MR> On 29-4-2014 14:45, Alex Peshkoff wrote: >> We do not have single fixed security database in FB3. Therefore us of it >> as jobs storage is not good choice. Adding new one looks better to me. >> But once again embedded problem is here - up to the fact that embedded >> user may have no rights to start daemons. MR> IMHO an embedded instance shouldn't do that. Only a normal server MR> install, if necessary through a separate daemon process (/windows MR> service) that is started separately. I would not mind to not have this feature for Embedded. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br |
|
From: Alex P. <pes...@ma...> - 2014-04-29 13:57:06
|
On 04/29/14 16:46, Daniel Rail wrote: > Hi, > > At April 29, 2014, 5:09 AM, Mark Rotteveel wrote: > >> On Tue, 29 Apr 2014 11:58:57 +0400, Dmitry Yemanov <fir...@ya...> >> wrote: >>> Who should initiate that dedicated listener deamon/user after a server >>> restart? Should the server attach all the databases itself to check >>> whether one needs a startup? What about databases unknown to the server >>> (not present in databases.conf)? >> If you look at SQL Server, there jobs themselves are not defined for a >> specific database (although they may depend on one or more databases). >> AFAIK they are stored in the master database. Execution requires an Agent >> service to be running. > And, even with the MS-SQL Agent service, it is no guarantee. We tried > setting up maintenance plans in MS-SQL 2012, and for some reason, the > maintenance plan file/record gets corrupted and will not work anymore, > and is no longer modifiable(and this is after creating multiple > maintenance plans, even after a full reinstall). So, we simply decided > to create a PowerShell script that will execute the maintenance tasks > and use the Windows Task Scheduler to schedule when the script will > run. > > So, for Firebird, I think that it would be up to the user and/or the > software developer to decide how they would want to execute such > tasks(either creating their own service, or using a batch/script to > execute the commands scheduled via a task scheduler). As an example, > our application has a service(for an n-tier application) that runs on > the server, and we simply add the maintenance tasks in it, and > they are scheduled when they are to be executed. > > So, for me, it is not something that I see as a priority for Firebird. > Since there is always another way of doing it. +1 I also do not see big need in a feature that can be easily replaced with std OS tools. |
|
From: Carlos H. C. <li...@wa...> - 2014-04-29 16:45:41
|
>> So, for Firebird, I think that it would be up to the user and/or the >> software developer to decide how they would want to execute such >> tasks(either creating their own service, or using a batch/script to >> execute the commands scheduled via a task scheduler). As an example, >> our application has a service(for an n-tier application) that runs on >> the server, and we simply add the maintenance tasks in it, and >> they are scheduled when they are to be executed. >>>> So, for me, it is not something that I see as a priority for Firebird. >> Since there is always another way of doing it. AP> +1 AP> I also do not see big need in a feature that can be easily replaced with AP> std OS tools. Well, most of the times, there are alternative ways of doing something. Afaiu, DY didn't restricted the list to only things that could not be done in alternative ways <g> Anyway, I'll not argue about priority. The tracker has a voting feature that can be used to measure this (although most people don't know about it). []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br |
|
From: Scott M. <bl...@bl...> - 2014-04-28 14:37:55
|
On 24/04/14 11:19, Dmitry Yemanov wrote: > This message is the invitation to both project members and users who > closely follow the development. UTC time zone support. Vital for international work and handy even for general use. It doesn't look like v3 has it (are we sure v3 can't catch this before it freezes?). Tickets CORE-694 and CORE-909 mention it. Scott |
|
From: Dmitry Y. <fir...@ya...> - 2014-04-28 18:23:47
|
28.04.2014 18:37, Scott Morgan wrote: >> This message is the invitation to both project members and users who >> closely follow the development. > > UTC time zone support. Vital for international work and handy even for > general use. Nice reminder, although I don't think it's trivial to implement. > It doesn't look like v3 has it (are we sure v3 can't catch this before > it freezes?). I'm afraid it cannot. Dmitry |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X