openinteract-dev — For OI developers, includes project coordination and technical discussion.

[Openinteract-dev] OpenInteract 2 issue

[Chris W. <ch...@cw...>]

I've been working a lot on the next version of OpenInteract. Many things
are changing -- all for the better, of course. One of the main goals is
to allow OI2 to run under different environments than Apache/mod_perl
1.x. In pursuing this goal I've run into a little sticking point that
maybe someone has some experience with. (I brought this up recently on
the P5EE mailing list if it sounds familiar...)

OI2 separates the monolithic OpenInteract::Request ($R) object into
three objects:

 - Context (configuration, lookups, service access, other runtime state
and resources)
 - Request (client info, cookies, session, GET/POST params)
 - Response (outbound cookies, headers, content, template info).

The Context is a singleton, created once at server startup and never
destroyed. Each incoming request creates a Request and Response object
to deal with that request. The Request and Response are then disposed
once the request is finished.

Originally I'd intended the Request and Response to be associated with
the Context. But AFAIK this will break horribly in a threaded
environment, since the Context would be considered a member of all
threads.

The only ways I see around this are:

 - Pass the request/response around everywhere. This seems to work for
Servlets ok. But there are pieces of the OI framework (like SPOPS
objects) that depend on getting information from the current request
(like the current user/groups) to do their jobs. Maybe this is too tight
a coupling and it needs to be rethought anyway.

 - Whenever we encounter a threaded environment, just create a new
Context object per thread and continue to associate the current
Request/Response with a context. I haven't used threads before so I
don't know how easy/feasible this is. (As a variation, we might be able
to keep the Context global but create a per-thread variable that
contains just the Request/Response and is accessible from anywhere in
the thread.)

Thanks for your ideas,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-dev] SPOPS fields names and case-sensitivity

[Ray Z. <rz...@co...>]

At 5:43 PM -0400 10/3/02, Chris Winters wrote:
>Shoot, while we're changing it why don't we just make it an object:
>
>  my $type_info = $spops_class->db_discover_types;
>  my $dbi_type = $type_info->get_type( $field );
>
>That would probably be the simplest and most explicit thing -- it's
>obvious what it does, and in the implementation 'get_type' wouldn't care
>what case $field was in. I don't think there'd be much more overhead
>than now, since we only keep one copy of the type information around
>anyway.
>
>What do you think?

Yeah, probably the best option.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Openinteract-dev] SPOPS fields names and case-sensitivity

[Chris W. <ch...@cw...>]

On Thu, 2002-10-03 at 13:43, Ray Zimmerman wrote:
> At 11:19 AM -0400 10/3/02, Chris Winters wrote:
> >  # keys \%dbi_types = ( 'foo', 'bar', 'baz' )
> >  foreach my $field ( @{ $fields } ) {
> >     my $field_type = $dbi_types->{ $field }; # uh oh, type not found!
> >  }
> 
> So that last line currently needs to be ...
> 
>      my $field_type = $dbi_types->{ lc $field };
> 
> ... in order to find the type, right?

Correct.
 
> Well, I suppose that would "fix" it. The reason it appeared as a 
> "bug" to me is that I always use consistent case between the SPOPS 
> config and the names in the database (which I thought should be as 
> safe as you can get), but we ran into problems with the 
> db_discover_types because it was returning a hash with lc'd keys.
> 
> I would prefer things being case sensitive everywhere, like a regular 
> Perl hash, but since SQL (or at least mysql) has case-insensitive 
> column names, I guess that's not a reasonable option.

Shoot, while we're changing it why don't we just make it an object:

 my $type_info = $spops_class->db_discover_types;
 my $dbi_type = $type_info->get_type( $field );

That would probably be the simplest and most explicit thing -- it's
obvious what it does, and in the implementation 'get_type' wouldn't care
what case $field was in. I don't think there'd be much more overhead
than now, since we only keep one copy of the type information around
anyway.

What do you think?

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-dev] SPOPS fields names and case-sensitivity

[Ray Z. <rz...@co...>]

At 11:19 AM -0400 10/3/02, Chris Winters wrote:
>But when we do an insert/update we want to match up the fields with
>their types, so we do something like:
>
>  my $fields = $class->field_list;
>  # $fields = [ 'FOO', 'BAR', 'BAZ' ]
>  my $dbi_types = $class->db_discover_types;
>  # keys \%dbi_types = ( 'foo', 'bar', 'baz' )
>  foreach my $field ( @{ $fields } ) {
>     my $field_type = $dbi_types->{ $field }; # uh oh, type not found!
>  }

So that last line currently needs to be ...

     my $field_type = $dbi_types->{ lc $field };

... in order to find the type, right?

>As a result, I don't know if we can change the return value of
>'db_discover_types', but I think we can change the return value of 'keys
>%{ $obj }' without too much difficulty.
>
>Well now that I think about it... maybe we can make the return of
>'db_discover_types' a tied hash as well. Unless, of course, you've got
>something else up your sleeve :-)

Well, I suppose that would "fix" it. The reason it appeared as a 
"bug" to me is that I always use consistent case between the SPOPS 
config and the names in the database (which I thought should be as 
safe as you can get), but we ran into problems with the 
db_discover_types because it was returning a hash with lc'd keys.

I would prefer things being case sensitive everywhere, like a regular 
Perl hash, but since SQL (or at least mysql) has case-insensitive 
column names, I guess that's not a reasonable option.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Openinteract-dev] SPOPS fields names and case-sensitivity

[Chris W. <ch...@cw...>]

On Wed, 2002-10-02 at 11:02, Ray Zimmerman wrote:
> We are running into some problems due to the way that SPOPS handles 
> field names. Specifically, it appears that keys($obj) always returns 
> a lower-case version of the actual field names, rather than the case 
> used in the configuration. Also, the db_discover_types() method in 
> SQLInterface returns a hash whose keys are the lower-cased field 
> names.
>
> Is there a good reason for this?  It seems like a bug to me.

The reason, of course, is laziness: I don't want to deal with dissonance
between what the database and the user thinks fields should be named. So
I just lowercase everything when dealing with fields.

For instance, what happens if a person does this?

config: {
   class => 'My::Foo',
   field => [ 'FOO', 'BAR', 'BAZ' ],
}

but as a result of a query to get the field names and types the database
returns:

 NAME   TYPE
 foo    SQL_VARCHAR,
 bar    SQL_INTEGER
 baz    SQL_TIMESTAMP

It's no problem when the user accesses fields, SPOPS::Tie takes care of
this:

 my $obj = My::Foo->fetch( 'quux' );
 print "Foo is: $obj->{FOO} $obj->{bar} $obj->{bAz}\n";

But when we do an insert/update we want to match up the fields with
their types, so we do something like:

 my $fields = $class->field_list;
 # $fields = [ 'FOO', 'BAR', 'BAZ' ]
 my $dbi_types = $class->db_discover_types;
 # keys \%dbi_types = ( 'foo', 'bar', 'baz' )
 foreach my $field ( @{ $fields } ) {
    my $field_type = $dbi_types->{ $field }; # uh oh, type not found!
 }

As a result, I don't know if we can change the return value of
'db_discover_types', but I think we can change the return value of 'keys
%{ $obj }' without too much difficulty.

Well now that I think about it... maybe we can make the return of
'db_discover_types' a tied hash as well. Unless, of course, you've got
something else up your sleeve :-)

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-dev] SPOPS fields names and case-sensitivity

[Ray Z. <rz...@co...>]

Chris,

We are running into some problems due to the way that SPOPS handles 
field names. Specifically, it appears that keys($obj) always returns 
a lower-case version of the actual field names, rather than the case 
used in the configuration. Also, the db_discover_types() method in 
SQLInterface returns a hash whose keys are the lower-cased field 
names.

Is there a good reason for this?  It seems like a bug to me.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

[Openinteract-dev] Re: ESPOPS, the future, and CPAN

[Ray Z. <rz...@co...>]

At 10:23 AM -0400 9/13/02, Chris Winters wrote:
>I have no problems with it. I apologize for not including it in the
>eons since you announced it, but I haven't had that particular itch
>yet :-)

I know how that goes ... I have (non-Perl) code that I've been 
"almost ready" to release for several years now.

>As for naming, that's up to you. SPOPS isn't an official namespace in
>the CPAN sense, but it might make sense for people looking around for
>the first time. I don't want to cause you renaming problems, however.
>
>I don't have any ideas for names. IIRC I was going to call this
>SPOPS::Inheritable, but that's not quite there I think.

You mean you don't quite like the name? Or that ESPOPS doesn't quite 
live up to that name yet?

>What does your
>team call it?

We just called it ESPOPS, but I figured I should give the name a bit 
more thought if I'm going to put it on CPAN.  What about doing 
something like was done with DBI, where there is also a DBIx 
namespace for things build on top of DBI. What do you think of 
SPOPSx::Inheritable?

>  > On a related note ... do you have an up-to-date SPOPS to do list somewhere?
>
>Not explicitly. My current plan is:
>
>  - Finish writing tests so that every major class in the system is
>  represented. (Almost done with this.) This is broader than it sounds
>  because various things shake out as a result. (As is happing right
>  now with security stuff.)

Isn't it amazing the number of bugs that can hide in code forever if 
you don't have comprehensive tests?

>  - Convert the rules, and make class generation behaviors, to use
>Class::Observable instead of the built-in scheme.

BTW, this seems like a reasonable idea to me. We've been using this 
design pattern along with ESPOPS objects and the only real stickler 
we ran into was circular references. We had an object Foo which has-a 
field containing a FooState object. When we made Foo and observer of 
FooState we got a circular reference. If you run into the same issue 
and are interested, I'll be happy to show you how we got around it.

>  - After that is working, I want to finally change the
>  linking/relationship declarations and behavior as you outlined.
>
>After that... it's time for 1.0 I think :-)

Yay!

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

[Openinteract-dev] Re: ESPOPS, the future, and CPAN

[Chris W. <ch...@cw...>]

* Ray Zimmerman (rz...@co...) [020912 11:26]:
> I'm not sure what the projections are regarding the inclusion of 
> ESPOPS functionality into SPOPS, but I was wondering what you thought 
> about me putting ESPOPS on CPAN in the mean time?
> 
> If you think it's a good idea, do you have any suggestions for a 
> better name for it?  Is it something you'd want me to put inside the 
> SPOPS namespace somewhere?

I have no problems with it. I apologize for not including it in the
eons since you announced it, but I haven't had that particular itch
yet :-)

As for naming, that's up to you. SPOPS isn't an official namespace in
the CPAN sense, but it might make sense for people looking around for
the first time. I don't want to cause you renaming problems, however.

I don't have any ideas for names. IIRC I was going to call this
SPOPS::Inheritable, but that's not quite there I think. What does your
team call it?

> On a related note ... do you have an up-to-date SPOPS to do list somewhere?

Not explicitly. My current plan is:

 - Finish writing tests so that every major class in the system is
 represented. (Almost done with this.) This is broader than it sounds
 because various things shake out as a result. (As is happing right
 now with security stuff.)

 - Convert the rules, and make class generation behaviors, to use
Class::Observable instead of the built-in scheme.

 - After that is working, I want to finally change the
 linking/relationship declarations and behavior as you outlined.

After that... it's time for 1.0 I think :-)

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988

[Openinteract-dev] Re: SPOPS-0.69 test failures

[Chris W. <ch...@cw...>]

* Ray Zimmerman (rz...@co...) [020912 10:48]:
> I'm getting a bunch of test failures with perl 5.8.0 and SPOPS-0.69. 
> I haven't tracked it down, but it looks like it could be due to 
> expecting hash keys or database rows to always appear in the same 
> order (i.e. forgetting to sort them).

Ouch. I'm going to have to get 5.8 installed somewhere so I can catch
this first.

Thanks for the report. I think I know how to solve this.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988

Re: [Openinteract-dev] SPOPS-0.69 test failures

[Chris W. <ch...@cw...>]

* Ray Zimmerman (rz...@co...) [020912 10:54]:
> ... and I forgot to mention that I believe Time::Piece is now 
> required in order to avoid dying during 'make test'. It's not in 
> 'PREREQ_PM' in Makefile.PL.

Yep -- I got this from one of the CPAN testers too. Thanks.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988

[Openinteract-dev] ESPOPS, the future, and CPAN

[Ray Z. <rz...@co...>]

Chris,

I'm not sure what the projections are regarding the inclusion of 
ESPOPS functionality into SPOPS, but I was wondering what you thought 
about me putting ESPOPS on CPAN in the mean time?

If you think it's a good idea, do you have any suggestions for a 
better name for it?  Is it something you'd want me to put inside the 
SPOPS namespace somewhere?

On a related note ... do you have an up-to-date SPOPS to do list somewhere?

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

[Openinteract-dev] ESPOPS-0.52 (Enhanced SPOPS)

[Ray Z. <rz...@co...>]

Here's the latest version of ESPOPS with a few minor changes.

	http://www.pserc.cornell.edu/ESPOPS/ESPOPS-0.52.tar.gz

ESPOPS stands for Enhanced SPOPS. Where standard SPOPS (or more
correctly, SPOPS::DBI) implements persistence for simple class of
objects whose data is stored in a single table, ESPOPS implements
persistence for a set of classes with inheritance relationships, where
the attributes are distributed across several tables, one for each class
in the inheritance hierarchy. (Similar to Tangram).

Our hope is that this functionality (not necessarily this code) will
eventually be included as part of the SPOPS distribution, along with the
new has-a and links-to functionality proposed on the openinteract-dev
list.

 From the Changes file, the updates since the last release (0.42) ...

0.52  Wed, Sep 11, 2002
     - Updated to sync with SPOPS-0.68. Minor changes to fetch() and
       fetch_group(). Removed docs for refetch() and field_update() since
       they are now in SPOPS::DBI.

0.51  Mon, Aug 12, 2002
     - Updated to sync with SPOPS-0.64. Minor changes to fetch() and save().
       Removed refetch() and field_update() since they are now in SPOPS::DBI.

0.50  Sat, Aug 3, 2002
     - Revamped the way objects are saved. Previously, the pre_save_action()
       method took care of getting things into the parent tables by creating
       parent objects and saving them (causing untold grief in implementing
       other pre_save_actions). The pre_save_action() method has been removed
       and a save() method has now been added. This method was copied directly
       from SPOPS::DBI::save() in SPOPS-0.61 and some small modifications made
       so that the object is successively blessed into each of the classes it
       inherits from (starting with ESPOPS::Object and ending with the class
       itself), and the appropriate _save_insert() or _save_update() is
       called. This eliminates the creation of parent objects via new and it
       eliminates the multiple calls to pre/post_save_action during a given
       object save. *** NOTE: THIS MAY CAUSE INCOMPATIBILITIES *** (e.g. the
       pre/post_save_action methods in Boat.pm in the tests had to be changed)
     - Replaced fetch() with one modified from the SPOPS::DBI::fetch() in
       SPOPS-0.61.
     - Replaced fetch_group() with one modified from SPOPS::DBI::fetch_group()
       in SPOPS-0.61. Unlike previous versions of ESPOPS::Object::fetch_group(),
       this version only does individual fetches for rows in the result of the
       initial db_select for which the 'class' field does not match the class
       used to call fetch_group(). So fetching many objects of the same class
       should be much faster if the correct class is used to call fetch_group.
       Fetching objects of different classes using a fetch_group called by a
       common base class will be done exactly as before.
     - Added e_has_a, and pre/post_fetch/save/remove_actions which handle
       forward direction auto fetching/saving/removing.
     - Added pm_fetch() method to do polymorphic fetch. Functionally identical
       to calling fetch_group with a where clause which is just an id clause.
     - Modified isa_classes() to return classes in order of proximity to
       current class in the inheritance tree. The calling class is always the
       first element and ESPOPS::Object is always the last element in the list.
       Modfied the order of tables in join created by fetch/fetch_group().
     - Added fetch_group_by_field() and fetch_group_by_ids() methods.
     - Added refetch() and field_update() methods. Currently do NOT work for
       inherited fields.
     - Added create_unless_exists() method, implemented by Raj.


-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Openinteract-dev] SPOPS-0.69 test failures

[Ray Z. <rz...@co...>]

... and I forgot to mention that I believe Time::Piece is now 
required in order to avoid dying during 'make test'. It's not in 
'PREREQ_PM' in Makefile.PL.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

[Openinteract-dev] SPOPS-0.69 test failures

[Ray Z. <rz...@co...>]

Chris,

I'm getting a bunch of test failures with perl 5.8.0 and SPOPS-0.69. 
I haven't tracked it down, but it looks like it could be due to 
expecting hash keys or database rows to always appear in the same 
order (i.e. forgetting to sort them).

Here's the output ...

ray@stealth:SPOPS-0.698% make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" 
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_base..................ok
t/01_tie...................ok
t/02_tie_strict............ok
t/03_uuid_key..............skipped
         all skipped: no reason given
t/04_random_key............ok
t/05_exception.............ok
t/06_ruleset...............ok
t/07_utility...............ok
         1/17 skipped: Weird timezone interaction
t/10_hash_file.............ok
t/20_gdbm..................ok
t/30_dbi...................ok
t/31_dbi_multifield........ok
t/32_dbi_inline_config.....ok
t/33_dbi_discover_field....ok
t/34_dbi_find_defaults.....ok
t/40_ldap..................skipped
         all skipped: no reason given
t/41_ldap_inline_config....skipped
         all skipped: no reason given
t/50_rule_create_only......ok
t/51_rule_read_only........ok
t/52_rule_date_convert.....ok
t/60_export_object.........NOK 8#     Failed test 
(t/60_export_object.t at line 81)
#          got: '$item = [
#   { spops_class => 'ExportObjectTest',
#     field_order => [ qw/ myname / ] },
#   [q{bar}],
#   [q{foo}],
#   [q{baz}],
# ];
# '
#     expected: '$item = [
#   { spops_class => 'ExportObjectTest',
#     field_order => [ qw/ myname / ] },
#   [q{foo}],
#   [q{bar}],
#   [q{baz}],
# ];
# '
t/60_export_object.........NOK 13#     Failed test 
(t/60_export_object.t at line 96)
#          got: '$item = [
#   { spops_class => 'ExportObjectTest',
#     field_order => [ qw/ myid myname / ] },
#   [q{2}, q{bar}],
#   [q{1}, q{foo}],
#   [q{3}, q{baz}],
# ];
# '
#     expected: '$item = [
#   { spops_class => 'ExportObjectTest',
#     field_order => [ qw/ myid myname / ] },
#   [q{1}, q{foo}],
#   [q{2}, q{bar}],
#   [q{3}, q{baz}],
# ];
# '
t/60_export_object.........ok 15/15# Looks like you failed 2 tests of 15.
t/60_export_object.........dubious
         Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 8, 13
         Failed 2/15 tests, 86.67% okay
t/61_export_xml............NOK 8#     Failed test (t/61_export_xml.t 
at line 93)
#          got: '<spops>
#   <spops-object>
#       <myname>bar</myname>
#   </spops-object>
#   <spops-object>
#       <myname>foo</myname>
#   </spops-object>
#   <spops-object>
#       <myname>baz</myname>
#   </spops-object>
# </spops>
# '
#     expected: '<spops>
#   <spops-object>
#       <myname>foo</myname>
#   </spops-object>
#   <spops-object>
#       <myname>bar</myname>
#   </spops-object>
#   <spops-object>
#       <myname>baz</myname>
#   </spops-object>
# </spops>
# '
t/61_export_xml............NOK 13#     Failed test (t/61_export_xml.t 
at line 108)
#          got: '<spops>
#   <spops-object>
#       <myid>2</myid>
#       <myname>bar</myname>
#   </spops-object>
#   <spops-object>
#       <myid>1</myid>
#       <myname>foo</myname>
#   </spops-object>
#   <spops-object>
#       <myid>3</myid>
#       <myname>baz</myname>
#   </spops-object>
# </spops>
# '
#     expected: '<spops>
#   <spops-object>
#       <myid>1</myid>
#       <myname>foo</myname>
#   </spops-object>
#   <spops-object>
#       <myid>2</myid>
#       <myname>bar</myname>
#   </spops-object>
#   <spops-object>
#       <myid>3</myid>
#       <myname>baz</myname>
#   </spops-object>
# </spops>
# '
t/61_export_xml............ok 15/15# Looks like you failed 2 tests of 15.
t/61_export_xml............dubious
         Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 8, 13
         Failed 2/15 tests, 86.67% okay
t/62_export_perl...........NOK 8#     Failed test (t/62_export_perl.t 
at line 71)
#          got: '$VAR1 = [
#           bless( {
#                    'myname' => 'bar',
#                    'myid' => 2
#                  }, 'ExportObjectTest' ),
#           bless( {
#                    'myname' => 'foo',
#                    'myid' => 1
#                  }, 'ExportObjectTest' ),
#           bless( {
#                    'myname' => 'baz',
#                    'myid' => 3
#                  }, 'ExportObjectTest' )
#         ];
# '
#     expected: '$VAR1 = [
#           bless( {
#                    'myname' => 'foo',
#                    'myid' => 1
#                  }, 'ExportObjectTest' ),
#           bless( {
#                    'myname' => 'bar',
#                    'myid' => 2
#                  }, 'ExportObjectTest' ),
#           bless( {
#                    'myname' => 'baz',
#                    'myid' => 3
#                  }, 'ExportObjectTest' )
#         ];
# '
t/62_export_perl...........ok 10/10# Looks like you failed 1 tests of 10.
t/62_export_perl...........dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 8
         Failed 1/10 tests, 90.00% okay
t/63_export_sql............NOK 8#     Failed test (t/63_export_sql.t 
at line 74)
#          got: 'INSERT INTO foo ( myname )
# VALUES ( 'bar' ) ;
# INSERT INTO foo ( myname )
# VALUES ( 'foo' ) ;
# INSERT INTO foo ( myname )
# VALUES ( 'baz' ) ;
# '
#     expected: 'INSERT INTO foo ( myname )
# VALUES ( 'foo' ) ;
# INSERT INTO foo ( myname )
# VALUES ( 'bar' ) ;
# INSERT INTO foo ( myname )
# VALUES ( 'baz' ) ;
# '
t/63_export_sql............NOK 13#     Failed test (t/63_export_sql.t 
at line 89)
#          got: 'INSERT INTO foo ( myid, myname )
# VALUES ( '2', 'bar' ) ;
# INSERT INTO foo ( myid, myname )
# VALUES ( '1', 'foo' ) ;
# INSERT INTO foo ( myid, myname )
# VALUES ( '3', 'baz' ) ;
# '
#     expected: 'INSERT INTO foo ( myid, myname )
# VALUES ( '1', 'foo' ) ;
# INSERT INTO foo ( myid, myname )
# VALUES ( '2', 'bar' ) ;
# INSERT INTO foo ( myid, myname )
# VALUES ( '3', 'baz' ) ;
# '
t/63_export_sql............ok 15/15# Looks like you failed 2 tests of 15.
t/63_export_sql............dubious
         Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 8, 13
         Failed 2/15 tests, 86.67% okay
t/64_export_dbdata.........NOK 8#     Failed test 
(t/64_export_dbdata.t at line 82)
#          got: '$item = [
#   { table => 'foo',
#     field_order => [ qw/ myname / ] },
#   [q{bar}],
#   [q{foo}],
#   [q{baz}],
# ];
# '
#     expected: '$item = [
#   { table => 'foo',
#     field_order => [ qw/ myname / ] },
#   [q{foo}],
#   [q{bar}],
#   [q{baz}],
# ];
# '
t/64_export_dbdata.........NOK 13#     Failed test 
(t/64_export_dbdata.t at line 97)
#          got: '$item = [
#   { table => 'foo',
#     field_order => [ qw/ myid myname / ] },
#   [q{2}, q{bar}],
#   [q{1}, q{foo}],
#   [q{3}, q{baz}],
# ];
# '
#     expected: '$item = [
#   { table => 'foo',
#     field_order => [ qw/ myid myname / ] },
#   [q{1}, q{foo}],
#   [q{2}, q{bar}],
#   [q{3}, q{baz}],
# ];
# '
t/64_export_dbdata.........ok 15/15# Looks like you failed 2 tests of 15.
t/64_export_dbdata.........dubious
         Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 8, 13
         Failed 2/15 tests, 86.67% okay
Failed Test          Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/60_export_object.t    2   512    15    2  13.33%  8 13
t/61_export_xml.t       2   512    15    2  13.33%  8 13
t/62_export_perl.t      1   256    10    1  10.00%  8
t/63_export_sql.t       2   512    15    2  13.33%  8 13
t/64_export_dbdata.t    2   512    15    2  13.33%  8 13
3 tests and 1 subtest skipped.
Failed 5/25 test scripts, 80.00% okay. 9/384 subtests failed, 97.66% okay.
make: *** [test_dynamic] Error 2


-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Openinteract-dev] test failures for SPOPS-0.68

[Chris W. <ch...@cw...>]

* Ray Zimmerman (rz...@co...) [020909 16:34]:
> t/32_dbi_inline_config.....1..4
> ok 1 - require SPOPS::Initialize;
> WARNING executing manipulate_configuration for DBIInlineTest
> Cannot create datasource access subroutine for (DBIInlineTest) 
> because you do not have 'dbi_config->dsn', 'dbi_config->username' and 
> 'dbi_config->username' defined
> ...

Hmm, the doubling of 'username' should have been a dead ringer :-)

I've modified this to allow an empty password. Thanks.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988

[Openinteract-dev] test failures for SPOPS-0.68

[Ray Z. <rz...@co...>]

Chris,

I'm getting the following test failure in SPOPS-0.68 (along with the 
#12 in t/07_utility.t at line 58 mentioned by someone else):

t/32_dbi_inline_config.....1..4
ok 1 - require SPOPS::Initialize;
WARNING executing manipulate_configuration for DBIInlineTest
Cannot create datasource access subroutine for (DBIInlineTest) 
because you do not have 'dbi_config->dsn', 'dbi_config->username' and 
'dbi_config->username' defined
Process will continue
ok 2 - Initialize process run
ok 3 - Initialize class
not ok 4 - Retrieved datasource from class
#     Failed test (t/32_dbi_inline_config.t at line 50)
# Looks like you failed 1 tests of 4.
dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 4
         Failed 1/4 tests, 75.00% okay

I do all of my testing using a 'test' database with a 'test' user and 
no password. I think the lack of a password is confusing it (the 
test, not mysql). All other tests pass fine and this one passes if I 
use a different user which has a password.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: [Openinteract-dev] SPOPS regression failure

[Chris W. <ch...@cw...>]

* Swen Thuemmler (sw...@me...) [020909 09:54]:
> Hmm, no. Only the timezone tests are skipped, not the today() check:

Open mouth, insert coffee. *Now* think...

Thanks,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988

Re: [Openinteract-dev] SPOPS regression failure

[Swen T. <sw...@me...>]

On Mon, Sep 09, 2002 at 08:32:23AM -0400, Chris Winters wrote:
> 
> You are correct, it should, and it's been changed. However, you might
> want to upgrade your Test::More -- this test was actually in a SKIP
> block since I was having weird timezone issues and couldn't get the test
> to succeed.

Hmm, no. Only the timezone tests are skipped, not the today() check:

[...]
SKIP: {
        skip( 'Weird timezone interaction', 1 );
        my $now = Class::Date->new({ time => $base_time })->strftime( '%Y-%m-%d %T' );
        is( $now, "$year-$mon-$mday $hour:$min:$sec", 'Default format for now()' );
    }
    my $today = SPOPS::Utility->today();
    is( $today, "$year-$mon-$mday", 'Format for today()' );
[...]

Sorry for nitpicking :-)

--Swen

Re: [Openinteract-dev] SPOPS regression failure

[Chris W. <ch...@cw...>]

On Mon, 2002-09-09 at 07:28, Swen Thuemmler wrote:
> Hi all,
>=20
> today I tried to install SPOPS 0.68. Unfortunately, one regression test f=
ailed:
>=20
> t/07_utility...............NOK 12#     Failed test (t/07_utility.t at lin=
e 58)
> #          got: '2002-09- 9'
> #     expected: '2002-09-09'
>=20
> Now I don't know wether this is a problem with the test suite or with
> SPOPS::Utility::today(). From the perldoc:
>     Return a date (yyyy-mm-dd) for today.
>=20
> But in the source:
> sub today { return $_[0]->now( { format =3D> '%Y-%m-%e' } ); }
>=20
> And from man strftime:
>   %e     Like %d, the day of the month as a decimal number, but a lead=AD
>          ing zero is replaced by a space. (SU)
>=20
> So I think the format should be changed to %Y-%m-%d=20

You are correct, it should, and it's been changed. However, you might
want to upgrade your Test::More -- this test was actually in a SKIP
block since I was having weird timezone issues and couldn't get the test
to succeed.

Thanks!

Chris

--=20
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-dev] SPOPS regression failure

[Swen T. <sw...@me...>]

Hi all,

today I tried to install SPOPS 0.68. Unfortunately, one regression test f=
ailed:

t/07_utility...............NOK 12#     Failed test (t/07_utility.t at lin=
e 58)
#          got: '2002-09- 9'
#     expected: '2002-09-09'

Now I don't know wether this is a problem with the test suite or with
SPOPS::Utility::today(). From the perldoc:
    Return a date (yyyy-mm-dd) for today.

But in the source:
sub today { return $_[0]->now( { format =3D> '%Y-%m-%e' } ); }

And from man strftime:
  %e     Like %d, the day of the month as a decimal number, but a lead=AD
         ing zero is replaced by a space. (SU)


So I think the format should be changed to %Y-%m-%d=20

Greetings, Swen

[Openinteract-dev] Re: [Poop-group] Changes to hasa()

[Chris W. <ch...@cw...>]

On Sat, 2002-09-07 at 10:17, Tony Bowden wrote:
> I had an interesting realization about hasa() yesterday ... it's really
> just a special case of the 'associate this column to this class'
> function that we currently have as associated_class().
> 
> So, I'd like to bring the two together. But there are several issues:
> 
> 1) They take their arguments in opposite directions!
> 
>     Foo->hasa(Class => column);
>     Foo->associated_class(column => Class);
> ...
> To make all of this simpler, I may just deprecate hasa() and
> associated_class() and replace both with a unified has_a() which 
> looks something like this:
> 
>   CD->has_a(artist => 'CD::Artist');
>   CD->has_a(release_date => 'Date::Simple');
> 
>   CD->has_a(last_update => 'Time::Piece::MySQL', 
>     in  => 'from_mysql_datetime',
>     out => 'mysql_datetime',
>   );
> 
>   CD->has_a(last_changed => 'Time::Piece',
>     in  => sub { Time::Piece->strptime(shift => "%d.%m.%Y") },
>     out => sub { shift->dmy('.') },
>   }

Ooo, great idea. This may be a nice area of convergence for SPOPS...

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-dev] editing templates via the browser

[Chris W. <ch...@cw...>]

On Sat, 2002-08-17 at 14:50, Randal L. Schwartz wrote:
> Just remember that when you save a file, you must save it to a unique
> temp name in the same directory, then rename it when complete.
> Otherwise, an async concurrent process may see a partially written
> file.

Point well taken. This is already done in the HTML filesystem page
editing module and I think I'm going to be able to reuse that code.
 
> This is in addition to any locking you want, or you can simply use a
> "last writer wins" strategy.

That's the favorite strategy of the lazy :-)

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-dev] editing templates via the browser

[<me...@st...>]

>>>>> "Chris" == Chris Winters <ch...@cw...> writes:

Chris> I'm finally going to fix editing templates in the browser. This has only
Chris> worked if you add your templates to the database, and using the
Chris> filesystem for template storage has been quietly touted since it was
Chris> implemented.

Chris> What I'd like to do is get rid of database storage for templates
Chris> altogether and use the new centralized package template storage in the
Chris> filesystem.

Just remember that when you save a file, you must save it to a unique
temp name in the same directory, then rename it when complete.
Otherwise, an async concurrent process may see a partially written
file.

This is in addition to any locking you want, or you can simply use a
"last writer wins" strategy.

TT got it wrong initially, and some people reported weird errors under
stress (and those are the toughest to fix!).

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[Openinteract-dev] SPOPS guts proposal: object rules

[Chris W. <ch...@cw...>]

Short and sweet: instead of using all the SPOPS::ClassFactory foo to set
object rules only at class initialization, you'll be able to add
observers to classes at startup or during program execution. The current
SPOPS methods dealing with pre/post actions and rulesets will go away or
become wrappers.

In their place, every SPOPS object will derive from Class::Observable.
It will let observers know about pre/post methods and will be able to
let observers know about other actions as well.

We should be able to support backward compatibility fairly easily, since
anonymous subroutines can be registered as observers to a class.

What do you think?

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-dev] editing templates via the browser

[Chris W. <ch...@cw...>]

I'm finally going to fix editing templates in the browser. This has only
worked if you add your templates to the database, and using the
filesystem for template storage has been quietly touted since it was
implemented.

What I'd like to do is get rid of database storage for templates
altogether and use the new centralized package template storage in the
filesystem. Here's how I'm thinking this would work:

 - install package; the templates are saved in the normal way to
$WEBSITE_DIR/pkg/foo-1.25/template/foo.tmpl
 - use website; templates are loaded from
$WEBSITE_DIR/pkg/foo-1.25/template/foo.tmpl
 - edit template; modified template is saved to
$WEBSITE_DIR/template/foo/foo.tmpl
 - use website; templates are now loaded from
$WEBSITE_DIR/template/foo/foo.tmpl
 - upgrade package; templates are still loaded from
$WEBSITE_DIR/template/foo/foo.tmpl and you can see the current package
templates at $WEBSITE_DIR/pkg/foo-1.26/template/foo.tmpl

So once you edit a template it gets copied to the central location and
is used for all packages thereafter. You'd be able to view the template
that shipped with a package and copy over information as necessary.

This would eliminate the need for all .meta files associated with
templates, and you'd be able to edit your templates either by editing a
file in the filesystem or by editing the template in the browser.

However, I haven't used templates in the database for some time. There
may be folks using this feature that have good reason. If you think we
should keep an option for templates in the database, speak up!

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.