Stoves

Thats both a cooker and a maker of them. Follow this link.

I bought a Stoves 700DFD0 cooker, gas hob, grill, double oven in December 2003, and paid quite a chunk of money for it. seven years on, I would like my money back. Never will I purchase anything from Stoves again.

The top oven/grill of my Stoves freestanding double oven has now broken down / stopped working for the third time in four years, each time the same problem and the replacement of the same part, the thermostat. On previous occasions we have a, got a repair company to fix it, b ordered the part ourself, and got a friend to fix it, and finally this time after it failed after nine monthes we got our electrician/repair man, who is a good friend, to speak directly to them and try and find what was going on. It seems that this part has now been replaced by a new design, not because it keeps breaking down, just because ...it has.

So we ordered the new part directly from Stoves and he came round to repair the cooker. The new part we had been sent is also faulty. As is the replacement part (new thermostat) for the main oven (which currently has the endearing, if somewhat dangerous habit, of turning itself on when it feels like it).

Other issues, besides the fact it breaks down on a regular basis. The stainless steel hob gets stained by any burnt food and is uncleanable. Gas Burners which don't sit properly and hence won't light. Wire cooking racks which no longer fit into their supports. An oven temperature 20 degrees higher than it should be AFTER allowing for the fan and which is hotter at the back than the front.

So if you want a new cooker, think hard about buying a "Stoves".

Physical ODS Changes for ODS 12

Posted to the Firebird Development list by Dimitry Yeamanov:

Below is the initial proposal (to be corrected/extended by others) that
describes the physical ODS changes we'd like to see in ODS 12.

Header page

* rework implementation ID to simplify the porting split into endianness and swap_double flags?)

* deprecate page buffers and sweep interval (in favor of the per-database values defined in .conf)


Pointer page / data page

* add "swept" flag
(allows to skip pages that have no dead or backversions, thus improving the GC / sweep performance)

Page inventory page

* use its own field instead of common "pag::reserved" (related to the misuse by PAG_allocate() happened in ODS 11.1)

New page type (bitmap?) to link SCNs to page numbers.
This may noticeably improve the incremental NBackup performance, avoiding reading pages not changed since the last backup.

Switch from SLONG to ULONG for transaction numbers and page numbers.

Extend blob length field from ULONG to UINT64 (and maybe allow blob levels higher than 2?).

Consider better alternative (instead of SQZ) for record compression.
Tests are required.
If not found, extend SQZ for sequences longer than 127 bytes.

Consider better packing of index key data (record numbers) and compound index keys (described by Jim in fb-architect).
Tests are required.
Extend the ACL format to cover new permission types and objects.

Additions are welcome, as well as questions/comments re. the
aforementioned items.

System Catalog Additions for ODS 12

The following appeared in the Firebird Development List from Dimitry Yemanov:

Here I'd like to have the possible additions to the system tables
discussed and agreed on. Physical ODS changes will be discussed in a
separate thread. As you understand, the sooner we have it resolved, the
easier it would be to set up the time frame for the v3.0 Alpha release.

I'll start with my own proposals, expecting others to follow up with
both comments/critique and their own suggestions. The changes already
done by Adriano are not included here.

RDB$FIELDS
+ RDB$SECURITY_CLASS (standard USAGE privilege for domains)
+ RDB$OWNER_NAME (prohibits altering/dropping domains by non-owners)

RDB$RELATIONS
+ RDB$STATISTICS (blob with binary statistics for the optimizer)

RDB$FUNCTIONS
+ RDB$FUNCTION_ID (allows metadata versioning for PSQL functions)
+ RDB$FUNCTION_BLR (BLR of a PSQL function)
+ RDB$VALID_BLR (BLR validation flag)
+ RDB$DEBUG_INFO (debug information)
+ RDB$LEGACY_FLAG (flag indicating whether this function is legacy
UDF style or new style)
+ RDB$SECURITY_CLASS (standard EXECUTE permission for functions)
+ RDB$OWNER_NAME (prohibits altering/dropping functions by non-owners)

RDB$FUNCTION_ARGUMENTS
+ RDB$ARGUMENT_NAME (input argument name)
+ RDB$FIELD_SOURCE (reference to a domain describing argument)
+ RDB$DEFAULT_SOURCE (default value for argument)
+ RDB$DEFAULT_BLR (default value BLR for argument)
+ RDB$COLLATION_ID (collation ID override for argument)
+ RDB$NULL_FLAG (null flag override for argument)
+ RDB$ARGUMENT_MECHANISM (full domain or TYPE OF)
+ RDB$FIELD_NAME (field name for TYPE OF)
+ RDB$RELATION_NAME (relation name for TYPE OF)

RDB$FILTERS
+ RDB$SECURITY_CLASS (USAGE privilege -- non standard, but probably
useful?)
+ RDB$OWNER_NAME (prohibits altering/dropping filters by non-owners)

RDB$GENERATORS
+ RDB$START_VALUE (start value per SQL standard)
+ RDB$INCREMENT_VALUE (increment value per SQL standard)
+ RDB$MIN_VALUE (minimum value per SQL standard)
+ RDB$MAX_VALUE (maximum value per SQL standard)
+ RDB$CYCLE_FLAG (cycle option per SQL standard)
+ RDB$SECURITY_CLASS (allows to have the standard USAGE privilege for
sequences)
+ RDB$OWNER_NAME (prohibits altering/dropping sequences by non-owners)

RDB$EXCEPTIONS
+ RDB$SECURITY_CLASS (USAGE privilege for exceptions -- non standard,
but probably useful?)
+ RDB$OWNER_NAME (prohibits altering/dropping by non-owners)

RDB$CHARACTER_SETS
+ RDB$SECURITY_CLASS (standard USAGE privilege)
+ RDB$OWNER_NAME (prohibits altering/dropping by non-owners)

RDB$COLLATIONS
+ RDB$SECURITY_CLASS (standard USAGE privilege)
+ RDB$OWNER_NAME (prohibits altering/dropping by non-owners)

As you can see, almost everything shown above is related to either
enhanced metadata security or implementation of PSQL functions.

I don't pretend to add all the aforementioned functionality in v3.0,
these fields can be reserved until actually used later.

I have intentionally avoided the "schemas / longer identifiers" topic
here, as IMO it deserves a separate discussion. Is anybody willing to
start it? :-)

New monitoring tables/fields will also be discussed separately.

Opinions?

Adriano, if you intend to switch from UNICODE_FSS to UTF8 in ODS12
system tables, let's please discuss it as well (here or in a different
thread).

USE_BLOCKING_THREAD

Another interesting email conversation between a developer and Dimitry Yemanov (Firebird core developer) produced this information:

Q.
What is the intent for the USE_BLOCKING_THREAD? I see it is enabled for all configurations except superserver. What is the rationale for that?

A.
The blocking thread (sometimes referred to as the AST delivery thread) listens for the blocking event notification posted by other processes and calls an appropriate BAST (blocking AST) routine inside the local process. This is necessary to asynchronously release or downgrade locks acquired by the current process but requested by other processes and is a vital part of the lock manager.

SuperServer doesn't need this feature as it performs direct AST calls from the lock requester to the lock holder (as everybody lives inside a single process).

The v2.5 embedded engine allows both in-process and cross-process interaction, thus it has the blocking thread enabled. For a single process embedded engine, USE_BLOCKING_THREAD may be undefined.

Cache flushes to disk and Firebird

The following fragment of a message appeared on the Firebird development list. As the question and answer are interesting, I thought I would put it on the blog.

"If I want to make cache flushes to disk very rare, do I set MaxUnflushedWrites & MaxUnflushedWriteTime to -1 or to some large value?
What other settings adjustments can make table flushes to disk more rare?
Is there any combination of settings that will keep the entire db in cache and never flush it to disk?"

Dimitry Yemanov answered as follows:

Forced writes = OFF (at the database level)
MaxUnflushedWrites = -1,
MaxUnflushedWriteTime = -1 (in firebird.conf)

With these settings, Firebird will never explicitly flush the cache to disk. However, flushes may still be performed by the operating system in the background. I believe you understand that these settings are somewhat risky from the database consistency point of view. There is no way to completely avoid flushes at all.

Firebird /Java Plugin Milestone One

Posted by Adriano in Firebird Development:

"I'm pleased to announce availability [1] of the first test version of
FB/Java plugin.

FB/Java is a plugin for FB external engines feature, to be presented in
v3.0, that allows execution of Java code at the server side. The plugin
allows classes/resources in the file system or stored in the database.
File system classes/resources are global and the code run with all
permissions. Database classes/resources are per-database and code runs
accordingly with per-engine configured security policy.

The plugin has been made with the assumption that anything could be done
using existing FB infrastructure. You don't need to setup FTP server or
shared directory in the server to update your code or edit security police.

Installation/update of database JARs works from client command line
utility or from SQLJ package procedures. Actually, the same Java class
that run in the client is the one that runs in the server. You can put
JARs in the database using a Java URL, so lookup of them is not
restricted to client or server.

Security handling is configured in a central database, with a single
PERMISSION table. Permissions are granted to users that executes the
Java code. This way to configure permissions is not adequate for every
(or most) cases, and roles are not supported at the moment. I suppose
and desire we can have a better design in the future, before a final
release.

It's welcome any attempt to bypass the security system. But please,
report it. :-)

This version also lacks some notification mechanism for when the code
are going to be unloaded. You may note the problem in the example, right
after disconnect all attachments from the database the log file remains
locked, as it wasn't been garbaged collected. And no kind of "hot
redeployment" support had been implemented or tested. However, I have
ideas of how these problems can be solved in very good ways, based on
existing models. For unloading (or any other type of notification),
JPA-like listeners. For maintain state after redeployments, serializable
sessions.

In the file plugins\java-engine\examples\fbjava\README, you found
instructions for a "quick start" with it. In
plugins\java-engine\examples\tests there are functional tests for many
of its feature (i.e., how type mappings works, etc).

The plugin is based on Jaybird 2.2 (HEAD). I've put it in a maven
repository at [2], with its version defined as 2.2-jrt-SNAPSHOT.

The server includes my v3.0 changes, supporting packages, DDL triggers,
over clause and some internal changes. It may have others instabilities.

If you have a JAVA_HOME environment variable defined, it should just
works without any other configuration. The quick start assumes you had
defined FIREBIRD, ISC_USER and ISC_PASSWORD. In [1], I've zipped plugin
and engine together, but plugin installation consists in just unpacking
it in FB directory.

Documentation has room for improvements, and is at [3]. I've done it
with FB docbook tools.

Source code is in [4].

Happy testing and thanks.
Adriano"

[1] http://www.firebirdsql.org/downloads/rabbits/asfernandes/fbjava/fbjava-m1.zip
[win32]
[2] http://www.firebirdsql.org/downloads/rabbits/asfernandes/maven2
[3] http://www.firebirdsql.org/downloads/rabbits/asfernandes/fbjava/fbjava.pdf
(included in [1])
[4] https://firebird.svn.sourceforge.net/svnroot/firebird/java-plugin/tags/2.2-jrt-M1

IBPhoenix Web Site

I need to post a note on my blog about the IBPhoenix Web site, it seems we are having problems with the T1 line. It looks like there is a problem in the central phone office, where our T1 line originates. It's been a problem now for several days. The issue has been escalated, so hopefully things will improve shortly.