Re: DBD::Oracle - rt13865.t
Do you have the DROP ANY TABLE privilege set for the userid?
That is the only DROP TABLE priv I can see, so I probably need to have
the dba grant it to my install-test user.
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run.
In Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does
this test not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP
TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr
0.07 csys = 0.25 CPU)
Result: PASS
Re: DBD::Oracle - rt13865.t
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run. In
Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does this test
not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07
csys = 0.25 CPU)
Result: PASS
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
DBD::Oracle - rt13865.t
I have to comment out the 'DROP TABLE' check to get this test to run.
In Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does
this test not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP
TABLE'};
}
Scott
Re: [rt.cpan.org #81516] Test failures due to hash randomisation in perl 5.17.6
On Sat, 1 Dec 2012 22:14:00 +, Tim Bunce wrote: > > Remaining question in that proposal: where's the fence between "must > > be last" and "insert unnamed attrs here"? > > I don't know, but I would like a working DBI for 5.17.6+ before too long. After some discussion on IRC, we agreed on this: http://svn.perl.org/viewvc/modules?view=revision&revision=15511 which is likely to be integrated into the main trunk and released the next DBI. > Tim. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Topics DBI::DBD::SqlEngine & derived
On Tue, 04 Dec 2012 18:52:06 +0100, Jens Rehsack
wrote:
> Hi Merijn,
Reply to summarize progress
> we should talk about
> - how to modify DBI::DBD::SqlEngine::TableSource and
>DBI::DBD::SqlEngine::DataSource to allow chaining
>(eg. fetch via http/ssh & decompress)
Still open, planned for today
> - easy way to configure the table-/datasources
Still open, planned for today
> - making DBD::CSV ready for dev-release (to get ideas about
>chop-blank errors)
Ready, thanks to intens coorporation on IRC. Waiting for a
SQL::Statement release. Then I'll release a new DBD::CSV
that depends on it
> - feature request:
>* skip-lines + columns line is first/second line
>* columns line is "commented"
No priority. I'll have to think about these
> - compatibility support for $dbh->{f_meta}
Open, planned for discussion on IRC today
> - RT#81516 (close connected to $dbh->{f_meta} stuff}
Two possible fixes were posted by Jens yesterday. We'd
really (yes, REALLY) appreciate feedback on that ASAP.
> It would be great if Sven could join the discussion
> for AnyData/DBD::AnyData work (to avoid doing incompatible
> stuff) and Tim as well as Martin to have more people with
> better knowledge about DBI::DBD::SqlEngine/DBD::File internals.
>
> I would also agree parts of the discussion happens via Skype,
> TeamSpeak (I can provide a server) or any other voice chat,
> if necessary.
Not an option in my $work environment
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [rt.cpan.org #81516] Test failures due to hash randomisation in perl 5.17.6
On 12.12.12 20:34, H.Merijn Brand wrote:
On Wed, 12 Dec 2012 16:31:44 +0100, Jens Rehsack
wrote:
On 01.12.12 23:14, Tim Bunce wrote:
On Thu, Nov 29, 2012 at 10:15:19PM +0100, Jens Rehsack wrote:
But back to the issue - now it seems dbm_tables is fetched earlier
in some cases than f_dir which causes an invocation of
DBI::DBD::SqlEngine::Table::get_table_meta (including
DBI::DBD::SqlEngine::Table::bootstrap_table_meta) before f_dir
has been set. This causes $dbh->{sql_meta}->{fred}->{f_dir} being
initialized to the default value of $dbh->{f_dir} which is
always cur_dir().
Looking into DBI::DBD::SqlEngine::dr::connect around line 180
it could be seen that there's already some magic for "some
settings must be done before others".
A quick fix for "now" could be: keys: ("sql_meta", $dbh->{dbm_meta},
...) must be initialized last - after any other k/v pair from %$attrs.
Another quick should could be forbid setting meta info during connect(),
as it's documented - but this would be a hugh step backwards in my
effort making DBI::DBD::SqlEngine and derived DBD's usable through
Gofer proxy. So I'd prefer the first quick shot ...
For longer way, I'd like to refactor the order procedure to a
more flexible way:
$dbh->{dbd_init_order} = [
[qw(Profile RaiseError PrintError AutoCommit)],
[qw(ReadOnly ...)],
...
[qw(sql_meta dbm_tables ...)]
];
Remaining question in that proposal: where's the fence between "must
be last" and "insert unnamed attrs here"?
I don't know, but I would like a working DBI for 5.17.6+ before too long.
Well, we developed two patches for now:
1) Merijn's patch - http://pasta.test-smoke.org/385
+ looks simple, easy to understand
+ easy to extend
+ easy to override
This is a good and bad point in once: easy to override allows
easy modifying the order, but it allows modifying the order
easily ;) This can cause in hard to debug errors like we got
one in RT#81516. And put a warning on it: use only if you
completely understood DBI::DBD::SqlEngine and DBD::File internals
is similar to: "don't do"
+ one single point of maintenance
Which ignores the design of DBI::DBD::SqlEngine which forces
a separate place for those kind of initializations:
DBD::Your_Drv::db::init_default_attributes.
- makes assumptions about attribute names of derived DBD's
(e.g. dbm_tables, but this can be easily renamed by assigning
new name for it to $dbh->{dbm_meta} (by driver author), eg.
$dbh->{dbm_meta} = "dbm_sources")
which makes me/us/you want more documentation about what DBI/DBD
guarantees, expects, supports etc. there is no real "you should do
this" or "this is officially off-bound"
Did you read DBD::File::Developers (and DBI::DBD::SqlEngine::Developers)?
I agree, those documents need to be extended, but many of the
things I tell are described there.
- increases complexitiy when more issues came up with similar
patterns (eg. /_meta$/ can't be set from outside, but from
derived driver)
but still offers easy documentation for every single entry
2) Jens' patch - http://pasta.test-smoke.org/387
+ backward compatible to ancient attributes (csv_file, csv_ext, ...)
though I value this point, we are talking about DBD's we all
control. The newest DBD::CSV and DBD::DBM will require the new DBI
so conflicts are not likely to happen. To be honest, I - as
maintainer of DBD::CSV - didn't even know csv_file was still
supported
My fault, I thought it would. But DBD::File supports dbm_ext (aliases
f_ext) as well as dbm_lockfile (aliases f_lockfile). I'm pretty sure,
DBD::AnyData (greetings to Sven Doweit) will have similar surprises.
+ no assumptions on derived DBD's
a very good point
+ no false positives on pattern match
if everything is well-documented, then false positives should not
happen or better cause havoc
- more complicated for quick review
can be solved by well-chosen inline docs
- This patch will probably need to have extra code in (many) other
places, which my patch tried to avoid
I wouldn't expect - I see only one extra point which is in DBD::File
to enable backward compatibility to DBD::File 0.40 for at least
developers (aliasing f_meta to sql_meta). Skipping this, even DBD::File
needs no extra code.
To value your comments, I've reworked my patch a little bit to allow
easier modifying in sub-classes (derived DBD's).
You can find it at http://pasta.test-smoke.org/389
Any other +/- comments?
Yes please, don't feel shy!
Tell us!
In general both versions would fix the root cause of RT#81516,
while the maintainers (Merijn, me) cannot choose the right one.
What he said
Jens
/o\
Jens
