Re: Spelling

[Martin J. Evans]

H.Merijn Brand wrote:
 On Tue, 08 Jun 2010 07:48:59 -0400, John Scoles sco...@pythian.com
 wrote:
 
 H.Merijn Brand wrote:
 Things I also noted:

 # 'DEFERABILITY' = (DEFER ABILITY DEFER-ABILITY DESIRABILITY 
 DURABILITY DIVISIBILITY)
 # 'deferrability' = (desirability durability divisibility)
 # 'DEFERRABILITY' = (DESIRABILITY DURABILITY DIVISIBILITY)
 The correct spelling is

 DEFERRABILITY though strictly speaking it is not an English word that
 should be used in a sentence. It is one of those messy ones where you
 have taken a verb 'defer' added 'able' to it (doubled the 'r' to keep
 the 'e' short) to get deferrable and then added 'ity' to turn it into
 an adjective.
 
 But I'm not going to touch that, as it looks like coming from some sort
 of base table from a standard. Martin?

The first one comes from the ODBC specification and I checked and it
should be DEFERRABILITY. However in SQL/CLI it is defined as
DEFERABILITY so the bracketed one (second instance) is also correct :-(

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Patches for DBD::CSV to use the tied f_meta access

[Jens Rehsack]

Hi Merijn,

attached the patch to allow DBD::CSV work fine with the
$dbh-{csv_tables} attribute.
It's for use with DBD::File rev. 14128. Maybe it's a good idea to set
some values into
$dbh-{csv_valid_attrs} and $dbh-{csv_readonly_attrs}, too - but you
know it better
than me.

Best regards,
Jens


DBD-CSV-csv_tables.patch
Description: Binary data

Re: DBD::File insert/update

[Jens Rehsack]

On 06/09/10 16:04, Tim Bunce wrote:

On Wed, Jun 09, 2010 at 02:45:18PM +, Jens Rehsack wrote:

On 06/09/10 14:36, Tim Bunce wrote:


The interface of the per-table API doesn't allow that :(
That's exactly the reason why I thought it's required to warn about that.


Can it be expressed as this is regarded as a bug and is likely to change?


It's a bug, it's a bug by design and yes, this is likely to change
(in distant future).
This behavior is listed under GOTCHAS AND WARNINGS (which seems to
be Jeffs place for describing BUGS AND LIMITATIONS.


It would be good to explicitly say it's a bug and it's likely to change.


I've added an explicitly =head1 for BUGS AND LIMITATIONS for this
paragraph.


Update could do a fetch_row first and fail if the row is not found.


This should happen. I try it and report.


Apart from the performance hit, what's the problem?


I rate a full table scan on INSERT not as a minor performance hit.
OTOH it's better to be slow than inconsistent.


Sure, but I was thinking specifically of hash/DBM style databases.


AFAIK - the table method push_row is now called only for adding
new rows (read: INSERT only). I have to double check before we
releasing a new DBI production release.

When I'm right, it's easy and reasonable fast to check, because no
explicit logic needs to be added to an SQL engine. But we should take
this as a reminder for designing new API for SQL::Statement 2.0 to
support more explicit methods for the several commands.

If you agree, I could now add a new method insert_row - which is
favored by the SQL engines over push_row. This might be safer than modifying
push_row and be surprised about other callers.


It's perfectly understandable (and NOT a bug) that things like CSV files
don't support unique constraints.


Not yet - but it's on TODO :)


On the other hand, databases built on hashes DO have a unique constraint
and silently discarding rows (on inserts) or inserting rows (on updates)
is a bug.


Jens