Sunday, 30 August 2009
The SPARQL Tutorial
Today's update (30 August 2009) includes a version of the ARQ SPARQL Tutorial and some associated fixes to the SPARQL subsystem. Specifically, default data sets should work better for the RDF application program.
Saturday, 22 August 2009
Better Numeric Types
Today's update (22 August) fixes a number of bugs mostly related to handling of numeric types. Two corrections to the syntax checking fix the BETWEEN predicate and named columns joins.
I really do like finding and fixing bugs!
I really do like finding and fixing bugs!
Friday, 14 August 2009
Subtype improvements
Today's update to the DBMS corrects the handling of the new URI-based subtypes of standard types. As mentioned in previous posts, these are a novelty in Pyrrho, allowing declarations such as
create type uk_numberplate as char with 'http://dvla.gov.uk'
As of today's version the representation clause ("as char" in this example) for such types is constrained to be a standard type. Subtypes of such types must be declared as follows:
create type sc_nunberplate under uk_numberplate as char with 'http://dvla.scotland.gov.uk'
The semantic of IS OF for these subtypes has been corrected.
create type uk_numberplate as char with 'http://dvla.gov.uk'
As of today's version the representation clause ("as char" in this example) for such types is constrained to be a standard type. Subtypes of such types must be declared as follows:
create type sc_nunberplate under uk_numberplate as char with 'http://dvla.scotland.gov.uk'
The semantic of IS OF for these subtypes has been corrected.
Saturday, 11 July 2009
Provenance again
Today's version of the software aims to fix a number of issues.
(a) a bug in transaction handling that resulted in premature closure of transactions
(b) a number of corrections to provenance handling and subtypes.
(c) a new system table called Sys$Object which makes it easier to see the provenance of tables and types.
To try out the new ideas, here are some examples.
1. To have database objects or inserted rows with a particular provenance, say something like
begin transaction with provenance 'http://example.com'
...
commit
Pyrrho refers to this internally as an import provenance, but of course it is more flexible than that.
2. To have rows in a table associated with a provenance, you can also say
insert with provenance '/data' into ...
and then the rows have a provenance consisting of eith or both the import and row provenance (if both are specified the provenance is the result of concatenating them).
There is no way of modifying provenance (this would be heresy).
3. Subtypes can be associated with a uri: there is a WITH syntax defined in Pyrrho for this purpose, e.g.
create type abcint as integer with 'http://abc.net'
and then if desired the subtype can be used for values you want to mark with the URI, by using (say) treat(11) as abcint instead of just 11.
Such a subtype behaves like an integer of course, but you can select on such subtype values using the OF predicate, e.g. select * from a where b is of(only abcint).
Write to me with any problems.
(a) a bug in transaction handling that resulted in premature closure of transactions
(b) a number of corrections to provenance handling and subtypes.
(c) a new system table called Sys$Object which makes it easier to see the provenance of tables and types.
To try out the new ideas, here are some examples.
1. To have database objects or inserted rows with a particular provenance, say something like
begin transaction with provenance 'http://example.com'
...
commit
Pyrrho refers to this internally as an import provenance, but of course it is more flexible than that.
2. To have rows in a table associated with a provenance, you can also say
insert with provenance '/data' into ...
and then the rows have a provenance consisting of eith or both the import and row provenance (if both are specified the provenance is the result of concatenating them).
There is no way of modifying provenance (this would be heresy).
3. Subtypes can be associated with a uri: there is a WITH syntax defined in Pyrrho for this purpose, e.g.
create type abcint as integer with 'http://abc.net'
and then if desired the subtype can be used for values you want to mark with the URI, by using (say) treat(11) as abcint instead of just 11.
Such a subtype behaves like an integer of course, but you can select on such subtype values using the OF predicate, e.g. select * from a where b is of(only abcint).
Write to me with any problems.
Thursday, 11 June 2009
Bug fixed: SelectedColumnsRowSet
In previous releases of v3.2, the rowType was incorrectly reported as the original rowType, not the rowType with just the selected columns. This would have caused an error 22202 when the wrong rowType was used.
Similar fixes to other RowSet classes. Fixed as of 12 June.
Similar fixes to other RowSet classes. Fixed as of 12 June.
Monday, 8 June 2009
On importing data
I've started to provide better support for data import into Pyrrho. Version 3.x has been introducing ideas of provenance. Now I am enhancing the PyrrhoMgr application a bit. The changes will get published in the next few days. So far they amount to:
1. Supporting direct import from Access 2007 in addition to Access 2003 and SQL Server.
2. Supporting the "Percent" numeric format in Access. (Intriguingly in Access 2007 the default Percent format is for a long integer, and so validation changes every value to either 0.0% or 100.0% !)
3. Allowing the importer to specify the "From Culture" so that culture specific formats for numbers and dates can get converted into the culture used by the importing thread (the culture of the machine that PyrrhoMgr is running on).
As mentioned in the last posting, the server always uses an invariant culture.
As a result of some ongoing research, more changes in this area can be expected soon.
1. Supporting direct import from Access 2007 in addition to Access 2003 and SQL Server.
2. Supporting the "Percent" numeric format in Access. (Intriguingly in Access 2007 the default Percent format is for a long integer, and so validation changes every value to either 0.0% or 100.0% !)
3. Allowing the importer to specify the "From Culture" so that culture specific formats for numbers and dates can get converted into the culture used by the importing thread (the culture of the machine that PyrrhoMgr is running on).
As mentioned in the last posting, the server always uses an invariant culture.
As a result of some ongoing research, more changes in this area can be expected soon.
Saturday, 6 June 2009
Why the version hasn’t changed
Changes like this are possible in Pyrrho because of the distinctive way that Pyrrho is designed. Nearly all DBMSs store data structures like indexes in permanent storage within the files making up the database. Pyrrho by contrast places in permanent storage only the data required for durability of each committed transaction. This approach minimises disk activity during normal operations, to about one-seventieth of the disk activity of rival systems.
The server’s data structures are private to the server, and are initialised when the server starts up, and the server brings its state up to date by re-reading the database file, which is just the transaction record. This is a time-consuming process for a large database, equivalent to a cold-start with resynchronisation step for other products.
The format of this data is as far as possible version and platform-independent – there is not even any assumption for what “double precision” means, or how many bits make up a long integer. This means that every aspect of the organisation of data structures can evolve without breaking backward compatibility. Database files created by version 0.1 can still be used in every version of Pyrrho, so all Pyrrho data bases can always be managed by the latest version of the server. New features, such as the recently introduced concept of provenance, or URI-based data types, introduce new or modified data formats which would not be understood by earlier versions, but they really should not be in use. Upgrading to the latest version is always recommended, and is free of charge.
The server’s data structures are private to the server, and are initialised when the server starts up, and the server brings its state up to date by re-reading the database file, which is just the transaction record. This is a time-consuming process for a large database, equivalent to a cold-start with resynchronisation step for other products.
The format of this data is as far as possible version and platform-independent – there is not even any assumption for what “double precision” means, or how many bits make up a long integer. This means that every aspect of the organisation of data structures can evolve without breaking backward compatibility. Database files created by version 0.1 can still be used in every version of Pyrrho, so all Pyrrho data bases can always be managed by the latest version of the server. New features, such as the recently introduced concept of provenance, or URI-based data types, introduce new or modified data formats which would not be understood by earlier versions, but they really should not be in use. Upgrading to the latest version is always recommended, and is free of charge.
Subscribe to:
Posts (Atom)
