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

Re: AW: [Openinteract-dev] DB handle caching

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

And...@Be... wrote:
> .. well for the stash:
> 
> there is a "db-main"=>1 added in the KEEP hash, which would explain that.
> Maybe we added it sometime...

Ah, then that would explain it.

> I commented out Apache::DBI in WEBSITE_DIR/conf/apache.dat and in
> OpenInteract::ApacheStartup.pm.

Those should be the only places. In fact, I think the apache.dat that 
gets installed when you create a new website with newer versions of OI 
does not have Apache::DBI in it -- it's only specified in 
OpenInteract::ApacheStartup. Not that this would have helped you :-)

Chris

AW: [Openinteract-dev] DB handle caching

[<And...@Be...>]

.. well for the stash:

there is a "db-main"=3D>1 added in the KEEP hash, which would explain =
that.
Maybe we added it sometime...
I commented out Apache::DBI in WEBSITE_DIR/conf/apache.dat and in
OpenInteract::ApacheStartup.pm.

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Dienstag, 28. Januar 2003 16:47
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-dev] DB handle caching


And...@Be... wrote:
> ...
> anyway:=20
> - although declaring the new db in the server.ini and adding the =
hopefully
> right datasource parameter to the spops.perl files, the system would =
not
run
> stable, because it tried to find the OI system tables ( like =
sys_error )
> within the new database and vice versa
> - we guessed, that Apache::DBI was causeing the trouble, because it =
could
> not differentiate between the 2 different databases in one mysql =
instance
> - therefore we commented Apache::DBI out and restarted OI
> - now the application works as expected, but I worried about =
performance
> dropping because of not caching the db connections, so I looked at =
the
> connections and saw, that there were still persistent connections =
from OI
to
> the mysql server, which sort of distroyed my beliefs ;-)
>=20
> Could please s.o. explain to me, how this is possilble? Is =
Apache::DBI
used
> at all?

This is odd. I don't think OI is caching these database handles.=20
They're stored in the Stash class during the request and cleaned=20
out at the end of the request. Where did you comment out Apache::DBI?

That said, Apache::DBI shouldn't confuse the database handles=20
since they should have unique connection strings and therefore be=20
separate objects. Can you post the different datasource=20
configuration sections from the server.ini?

Chris

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

Re: [Openinteract-dev] DB handle caching

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

And...@Be... wrote:
> ...
> anyway: 
> - although declaring the new db in the server.ini and adding the hopefully
> right datasource parameter to the spops.perl files, the system would not run
> stable, because it tried to find the OI system tables ( like sys_error )
> within the new database and vice versa
> - we guessed, that Apache::DBI was causeing the trouble, because it could
> not differentiate between the 2 different databases in one mysql instance
> - therefore we commented Apache::DBI out and restarted OI
> - now the application works as expected, but I worried about performance
> dropping because of not caching the db connections, so I looked at the
> connections and saw, that there were still persistent connections from OI to
> the mysql server, which sort of distroyed my beliefs ;-)
> 
> Could please s.o. explain to me, how this is possilble? Is Apache::DBI used
> at all?

This is odd. I don't think OI is caching these database handles. 
They're stored in the Stash class during the request and cleaned 
out at the end of the request. Where did you comment out Apache::DBI?

That said, Apache::DBI shouldn't confuse the database handles 
since they should have unique connection strings and therefore be 
separate objects. Can you post the different datasource 
configuration sections from the server.ini?

Chris

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

[Openinteract-dev] DB handle caching

[<And...@Be...>]

Hey y'all,

we just fell over s.th. strange, that I hope you knowing mailing list
readers are able to resolve:

- we use a variety of mysql and oracle databases under OI with one db =
on
each host, so far
- on our test system we tried to imitate this by separating tables to
multiple mysql database within the same db instance
- our aim with this is to separate the tables of each major application =
to
one database

anyway:=20
- although declaring the new db in the server.ini and adding the =
hopefully
right datasource parameter to the spops.perl files, the system would =
not run
stable, because it tried to find the OI system tables ( like sys_error =
)
within the new database and vice versa
- we guessed, that Apache::DBI was causeing the trouble, because it =
could
not differentiate between the 2 different databases in one mysql =
instance
- therefore we commented Apache::DBI out and restarted OI
- now the application works as expected, but I worried about =
performance
dropping because of not caching the db connections, so I looked at the
connections and saw, that there were still persistent connections from =
OI to
the mysql server, which sort of distroyed my beliefs ;-)

Could please s.o. explain to me, how this is possilble? Is Apache::DBI =
used
at all?

thanks for your time,


Andreas Nolte
Leitung IT
-----------------------------------------------------------
arvato direct services=20
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/

and...@be...
Phone   +49 (0) 4421 - 76- 84002
Fax	+49 (0) 4421 - 76- 84111

Re: [Openinteract-dev] anyone knowledgable about cross-platform datatypes?

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

Andrew Hurst wrote:
> At 11:49 AM 1/6/2003 -0500, you wrote:
>> Date/time formatting is *MUCH* worse, but fortunately that can be 
>> dealt with almost entirely within the application logic. Someone 
>> else's problem :-)
> 
> Forgive me if I'm asking an obvious question, as I haven't actually 
> gotten OI running on my machine here yet, but how will this work?  Will 
> you set it up so that no matter what the database it returns the date in 
> a standard format?  like DD-MM-YYYY HH:MI:SS, then require the app to 
> format it as necessary...   Will there be a set of routines for 
> formatting it built-in?  I've used Date::Calc and Date::Format before 
> and they worked rather well, thought I'm not sure about speed/size 
> (never had the need to check on them before).

Currently OI doesn't really care what format the date is in. My 
problem with the different types comes about because we have to 
create the schema -- no choice there.

OI relies on you to know your database and what format the dates 
are returned in and what they need for an insert/update. This is 
partly a cop-out, but there aren't too many places where we have 
to rely on a date/time being in a particular format. When this 
does come up...

> I could see the db driver always returning it in the same format, then 
> requiring it to be input in the same format as well.  Maybe a 
> format_for_db() function, taking the format you currently have the date 
> in and the date, and it returning the string formatted for what the 
> driver expects..

...we can use SPOPS::Tool::DateConvert to coerce a database date 
into a standard object (likely Time::Piece). That buys us the 
same interface for all dates no matter where they're from.

Then on insert/update we need to put the date object into the 
necessary database format. The SPOPS tool allows you to specify 
the date type in a strftime format for parsing, so it's pretty 
simple to declare and transparent to use.

I'll stick a note about this on the wiki for whenever the 
packages get converted to the OI2.

Chris

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

Re: [Openinteract-dev] anyone knowledgable about cross-platform datatypes?

[Andrew H. <hu...@ll...>]

At 11:49 AM 1/6/2003 -0500, you wrote:
>Andrew Hurst wrote:
>...
>>special cases for it.  What might be worse is the date/time formatting, I 
>>doubt that it's standardized.
>
>Date/time formatting is *MUCH* worse, but fortunately that can be dealt 
>with almost entirely within the application logic. Someone else's problem :-)

Forgive me if I'm asking an obvious question, as I haven't actually gotten 
OI running on my machine here yet, but how will this work?  Will you set it 
up so that no matter what the database it returns the date in a standard 
format?  like DD-MM-YYYY HH:MI:SS, then require the app to format it as 
necessary...   Will there be a set of routines for formatting it 
built-in?  I've used Date::Calc and Date::Format before and they worked 
rather well, thought I'm not sure about speed/size (never had the need to 
check on them before).

I could see the db driver always returning it in the same format, then 
requiring it to be input in the same format as well.  Maybe a 
format_for_db() function, taking the format you currently have the date in 
and the date, and it returning the string formatted for what the driver 
expects...

Anyway, thats my rambling thoughts.  Is that what you meant above?

-Andrew


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

Re: [Openinteract-dev] anyone knowledgable about cross-platform datatypes?

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

Andrew Hurst wrote:
>> So my question is: is there any consistent column type for this, or do 
>> I need to make this vary among database vendors as well?
> 
> I haven't looked into it too much, but to add one more data point to the 
> list, Oracle uses 'date' columns which store the date and the time.  I 
> would expect you need to make this vary among the vendors, and have 

Yeah, I was afraid of this. Thanks for the Oracle note.

I'll probably make this change in the next release.

> special cases for it.  What might be worse is the date/time formatting, 
> I doubt that it's standardized.

Date/time formatting is *MUCH* worse, but fortunately that can be 
dealt with almost entirely within the application logic. Someone 
else's problem :-)

Chris

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

Re: [Openinteract-dev] anyone knowledgable about cross-platform datatypes?

[Andrew H. <hu...@ll...>]

At 10:41 PM 1/5/2003 -0500, you wrote:
>This is a simple SQL question, but I figured there are enough folks on 
>here who work with different database platforms to know: what's the most 
>common datatype to hold a date and time value? I've been using 'datetime', 
>but that seems to have gone away in the newest PostgreSQL release, being 
>replaced by 'timestamp'
>
>The type 'timestamp' is referenced as a SQL-92 datatype [1], but a MySQL 
>page [2] uses 'timestamp' as a date plus time that is automatically set to 
>the time of the last insert/update. FirebirdSQL/InterBase also seem to use 
>'timestamp' as a datetime column type.
>
>So my question is: is there any consistent column type for this, or do I 
>need to make this vary among database vendors as well?

I haven't looked into it too much, but to add one more data point to the 
list, Oracle uses 'date' columns which store the date and the time.  I 
would expect you need to make this vary among the vendors, and have special 
cases for it.  What might be worse is the date/time formatting, I doubt 
that it's standardized.

-Andrew



>Thanks,
>
>Chris
>
>[1] http://www.commandprompt.com/ppbook/index.lxp?lxpwrap=x2632%2ehtm
>[2] 
>http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#DATETIME
>[3] http://www.firebirdsql.org/index.php?op=faq
>--
>Chris Winters (ch...@cw...)
>Building enterprise-capable snack solutions since 1988.
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>openinteract-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev

[Openinteract-dev] anyone knowledgable about cross-platform datatypes?

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

This is a simple SQL question, but I figured there are enough folks 
on here who work with different database platforms to know: what's 
the most common datatype to hold a date and time value? I've been 
using 'datetime', but that seems to have gone away in the newest 
PostgreSQL release, being replaced by 'timestamp'

The type 'timestamp' is referenced as a SQL-92 datatype [1], but a 
MySQL page [2] uses 'timestamp' as a date plus time that is 
automatically set to the time of the last insert/update. 
FirebirdSQL/InterBase also seem to use 'timestamp' as a datetime 
column type.

So my question is: is there any consistent column type for this, or 
do I need to make this vary among database vendors as well?

Thanks,

Chris

[1] http://www.commandprompt.com/ppbook/index.lxp?lxpwrap=x2632%2ehtm
[2] 
http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#DATETIME
[3] http://www.firebirdsql.org/index.php?op=faq
-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

[Openinteract-dev] Re: SPOPS 0.72 (and 0.73) broken

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

At 8:48 AM -0500 1/3/03, Chris Winters wrote:
>Tell me about it. Sometimes I wish I were still doing Perl full-time...

Yup. The better I get with Perl the more I like it.

>Can you grab/test SPOPS 0.74 before I release it and run the ESPOPS 
>tests against it to see how they go?
>
>  http://www.cwinters.com/raw/SPOPS-0.74.tar.gz

After adding a call to as_hash() at the appropriate place in ESPOPS, 
all of the SPOPS and ESPOPS tests are passing nicely for me again.

Ship it!

-- 
  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: SPOPS 0.72 (and 0.73) broken

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

Ray Zimmerman wrote:
> Ah ... case-sensitivity stuff ... now I remember vaguely why you're 
> doing this ... I'm too young for my memory to be going already :-)

Tell me about it. Sometimes I wish I were still doing Perl full-time...

Can you grab/test SPOPS 0.74 before I release it and run the ESPOPS 
tests against it to see how they go?

  http://www.cwinters.com/raw/SPOPS-0.74.tar.gz

Thanks,

Chris

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

[Openinteract-dev] Re: SPOPS 0.72 (and 0.73) broken

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

At 12:24 AM -0500 1/3/03, Chris Winters wrote:
>Just a follow-up: I added an 'as_hash()' method to the 
>SPOPS::DBI::TypeInfo class, so you can do:
>
>  my %type_map = $type_info->as_hash;
>  foreach my $field ( keys %type_map ) {
>      print "Field $field is type $type_map{ $field }\n";
>  }
>
>You may still run into the case-sensitivity problem from before 
>(fields are in whatever case specified or as they were retrieved 
>from the database), but that's your problem now that there's an 
>alternative ;-)

Ah ... case-sensitivity stuff ... now I remember vaguely why you're 
doing this ... I'm too young for my memory to be going already :-)

-- 
  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: SPOPS 0.72 (and 0.73) broken

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

At 11:41 PM -0500 1/2/03, Chris Winters wrote:
>>So your example of how to use db_discover_types() is no longer valid, is it?
>
>Nope. I must have pulled that from the wayback machine by accident. 
>Your example is correct and has been placed into the docs for 
>SPOPS::SQLInterface. Thanks.

Well, it wasn't exactly *my* example ... after all I did pretty much 
get it straight from the SPOPS::DBI::TypeInfo docs.

-- 
  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: SPOPS 0.72 (and 0.73) broken

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

Ray Zimmerman wrote:
> ... maybe I missed it, but I didn't see a way to get back the old hash 
> that my code was using. In any case, I can change my code to use the new 
> TypeInfo object instead of the hash ... it's not a big problem.

Just a follow-up: I added an 'as_hash()' method to the 
SPOPS::DBI::TypeInfo class, so you can do:

  my %type_map = $type_info->as_hash;
  foreach my $field ( keys %type_map ) {
      print "Field $field is type $type_map{ $field }\n";
  }

You may still run into the case-sensitivity problem from before 
(fields are in whatever case specified or as they were retrieved 
from the database), but that's your problem now that there's an 
alternative ;-)

Chris

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

[Openinteract-dev] Re: SPOPS 0.72 (and 0.73) broken

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

Ray Zimmerman wrote:
> I'm back after some time off ...

Hope your holidays were excellent.

> First, I'm getting test 37 failing for t/30_dbi.t ...
> 
> not ok 37 - Field update (multiple object) execution
> #     Failed test (t/30_dbi.t at line 260)
> #          got: '2'
> #     expected: '3'
> 
> ... and a bunch of my ESPOPS tests (which work fine with SPOPS-0.70) 
> still break. Let me respond to your previous e-mail on field_update() ...

Hm, that's interesting. I probably should have tried this out on 
another database before releasing...

> As it stands, I think field_update() always returns true, even if no 
> rows were affected.
> 
> So, I still think the "$rv = ( $rv != 0 )" code from 0.70 is what we (or 
> at least I :-) want.

I just ran the tests with SQLite and got errors in that DBI test 
(plus one other) as well. So this will be going back. Oh well, 
confidence borne of ignornace and all that.

> Ah ... whoops ... all_field_types() was an ESPOPS method that calls 
> db_discover_types(), as you suggest, with the various classes/tables 
> that make up an object with inherited fields.
> 
> However, it looks like db_discover_types() is now returning a 
> SPOPS::DBI::TypeInfo object instead of a simple hash ... I never 
> installed SPOPS-0.71 so I missed this change ... lemme go have a look at 
> the docs for this class ...
> 
> ... hey, the docs thank me for pointing out the need for the 
> functionality in this module ... am I forgetting something or are you 
> just starting to put my name in the credits out of habit :-)

Ha! I should start pasting links to the email archives....

> So your example of how to use db_discover_types() is no longer valid, is 
> it?

Nope. I must have pulled that from the wayback machine by accident. 
Your example is correct and has been placed into the docs for 
SPOPS::SQLInterface. Thanks.

Chris

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

[Openinteract-dev] SPOPS 0.72 (and 0.73) broken

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

I'm back after some time off ...

First, I'm getting test 37 failing for t/30_dbi.t ...

not ok 37 - Field update (multiple object) execution
#     Failed test (t/30_dbi.t at line 260)
#          got: '2'
#     expected: '3'

... and a bunch of my ESPOPS tests (which work fine with SPOPS-0.70) 
still break. Let me respond to your previous e-mail on field_update() 
...

At 10:40 AM -0500 12/24/02, Chris Winters wrote:
>Ray Zimmerman wrote:
>>I think that's still wrong ... $rv = ( $rv != 0 ) was correct.
>
>But this removes information that might be useful: returning $rv 
>gives an indication of the number of rows affected while still 
>retaining the "return false if no rows affected" semantics. So you 
>can still do:
>
>  my $rows = $class->field_update( ... );
>  if ( $rows ) {
>      print "$rows rows affected";
>  }
>  else {
>      print "No rows affected";
>  }

If I understand things correctly, this code will not do what you 
expect. The problem is precisely that it doesn't retain the "return 
false if no rows affected" semantics. If no rows are affected $rows 
will be '0E0' which is a true value for which $rows == 0 is also true.

 From the DBI docs ...

"A successful execute always returns true regardless of the number of 
rows affected, even if it's zero"

... and ...

"For a non-SELECT statement, execute returns the number of rows 
affected, if known. If no rows were affected, then execute returns 
``0E0'', which Perl will treat as 0 but will regard as true. Note 
that it is not an error for no rows to be affected by a statement. If 
the number of rows affected is not known, then execute returns -1."

As it stands, I think field_update() always returns true, even if no 
rows were affected.

So, I still think the "$rv = ( $rv != 0 )" code from 0.70 is what we 
(or at least I :-) want.

>>>How were you retrieving/using the field types?
>>
>>I was calling $self->all_field_types() then checking types against 
>>constants defined in DBI.
>
>You should be able to use something like:
>
>  my $type_hash = $class->db_discover_types( $class->table_name );
>  foreach my $field ( keys %{ $type_hash } ) {
>      print "$field is DBI type $type_hash->{ $field }\n";
>  }
>
>SQLInterface->db_discover_types is still the front end for retriving 
>the types, and under the covers we're still using DBI types, just 
>getting them in a cleaner manner.

Ah ... whoops ... all_field_types() was an ESPOPS method that calls 
db_discover_types(), as you suggest, with the various classes/tables 
that make up an object with inherited fields.

However, it looks like db_discover_types() is now returning a 
SPOPS::DBI::TypeInfo object instead of a simple hash ... I never 
installed SPOPS-0.71 so I missed this change ... lemme go have a look 
at the docs for this class ...

... hey, the docs thank me for pointing out the need for the 
functionality in this module ... am I forgetting something or are you 
just starting to put my name in the credits out of habit :-)

So your example of how to use db_discover_types() is no longer valid, is it?

Shouldn't it be ...

  my $type_info = $class->db_discover_types( $class->table_name );
  foreach my $field ( $type_info->get_fields ) {
      print "$field is DBI type " . $type_info->get_type( $field ) . "\n";
  }

... maybe I missed it, but I didn't see a way to get back the old 
hash that my code was using. In any case, I can change my code to use 
the new TypeInfo object instead of the hash ... it's not a big 
problem.

-- 
  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] Re: SPOPS 0.72 broken

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

Ray Zimmerman wrote:
> I think that's still wrong ... $rv = ( $rv != 0 ) was correct.

But this removes information that might be useful: returning $rv 
gives an indication of the number of rows affected while still 
retaining the "return false if no rows affected" semantics. So 
you can still do:

  my $rows = $class->field_update( ... );
  if ( $rows ) {
      print "$rows rows affected";
  }
  else {
      print "No rows affected";
  }

>> How were you retrieving/using the field types?
> 
> I was calling $self->all_field_types() then checking types against 
> constants defined in DBI.

You should be able to use something like:

  my $type_hash = $class->db_discover_types( $class->table_name );
  foreach my $field ( keys %{ $type_hash } ) {
      print "$field is DBI type $type_hash->{ $field }\n";
  }

SQLInterface->db_discover_types is still the front end for 
retriving the types, and under the covers we're still using DBI 
types, just getting them in a cleaner manner.

Happy holidays!

Chris

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

[Openinteract-dev] Re: SPOPS 0.72 broken

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

At 5:52 PM -0500 12/23/02, Chris Winters wrote:
>I think you're right. I modified this in CVS to just return $rv 
>instead. I'll probably put out a new version shortly, just as soon 
>as I get something built to do automatic document building for the 
>SPOPS website.

I think that's still wrong ... $rv = ( $rv != 0 ) was correct.

>>I suspect my other problems are related to the changes to the way 
>>type_info is handled.
>
>How were you retrieving/using the field types?

I was calling $self->all_field_types() then checking types against 
constants defined in DBI.

-- 
  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: SPOPS 0.72 broken

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

Ray Zimmerman wrote:
> It seems like there are a few things broken in SPOPS-0.72 which are 
> causing a bunch of my ESPOPS tests to fail.
> 
> Two things I noticed are that the 'if_match' handling of field_update() 
> seems to be broken and all_field_types() returns a hash with all undefs 
> for the values.
> 
> I'm pretty sure changing ...
> 
>     $rv = ( $rv != 0 );
> 
> ... to ...
> 
>     $rv = ( $rv ne '0' );
> 
> ... near the end of field_update() is a bug. Normally, if the update 
> does not modify any rows it will return a "true" zero value, namely '0E0'.

I think you're right. I modified this in CVS to just return $rv 
instead. I'll probably put out a new version shortly, just as 
soon as I get something built to do automatic document building 
for the SPOPS website.

> I suspect my other problems are related to the changes to the way 
> type_info is handled.

How were you retrieving/using the field types?

> Merry Christmas!

Same to you!

Chris

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

[Openinteract-dev] SPOPS 0.72 broken

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

Chris,

It seems like there are a few things broken in SPOPS-0.72 which are 
causing a bunch of my ESPOPS tests to fail.

Two things I noticed are that the 'if_match' handling of 
field_update() seems to be broken and all_field_types() returns a 
hash with all undefs for the values.

I'm pretty sure changing ...

     $rv = ( $rv != 0 );

... to ...

     $rv = ( $rv ne '0' );

... near the end of field_update() is a bug. Normally, if the update 
does not modify any rows it will return a "true" zero value, namely 
'0E0'.

I suspect my other problems are related to the changes to the way 
type_info is handled.

Merry Christmas!

-- 
  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] tmplib

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

And...@Be... wrote:
> In this context we found out, that currenty the tmplib path is hard coded in
> OpenInteract::Startup.pm. Would it hurt to change that to a diffent path, so
> that each machine has a local copy? If not ( as I assume ), should this be
> configurable in server.perl/ini ?

Excellent idea. I'll put it in for the next version.

Chris

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

[Openinteract-dev] tmplib

[<And...@Be...>]

Hey y' all,

we finally got around to install some new hardware to have a multiple
machines serving as the web/application server using the same databases =
and
website_dir etc. over NFS.=20

In general, this really works out as expected , if you reconfigure
everything, which should be stored on the local machine and not the =
shared
NFS server ( like logs, cache, etc. ) to use a local disk.

In this context we found out, that currenty the tmplib path is hard =
coded in
OpenInteract::Startup.pm. Would it hurt to change that to a diffent =
path, so
that each machine has a local copy? If not ( as I assume ), should this =
be
configurable in server.perl/ini ?

later,

Andreas Nolte
Leitung IT
-----------------------------------------------------------
arvato direct services=20
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/

and...@be...
Phone   +49 (0) 4421 - 76- 84002
Fax	+49 (0) 4421 - 76- 84111

[Openinteract-dev] SPOPS now its own SF project

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

I've moved SPOPS into its own Sourceforge project. For now, the 
main effect of this is that the sourcecode now has a new CVS 
repository -- you won't be able to checkout/update the code from 
the OI repository any longer. And the nice folks at SF moved the 
CVS files to the new project so the history is maintained.

New home:

   http://sourceforge.net/projects/spops/
   http://spops.sourceforge.net/ (nothing there yet)

More soon...

Chris

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

Re: AW: [Openinteract-dev] OpenInteract 2 issue

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

On Mon, 2002-11-11 at 02:26, And...@Be... wrote:
> since the new ithread environment is a shared nothing thread env per
> default, you have to share everything expicitly, which gives you a lot or
> control. If you keep the context a singleton which does the appropriate
> lock($myvar) things in the accessor methods on write access, there should
> not be a problem. In a non threaded env lock() is a noop.

This makes a lot of sense and shouldn't be too difficult to deal with.

> Also, there are quite a lot of interesting bits of Thread code on CPAN -
> Thread::Pool maybe beeing the most interesting...

I'll probably wait and see what threaded server implementations come up
first :-) (There are enough fish to fry for now...)

Thanks,

Chris

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

AW: [Openinteract-dev] OpenInteract 2 issue

[<And...@Be...>]

Hi Chris,

since the new ithread environment is a shared nothing thread env per
default, you have to share everything expicitly, which gives you a lot =
or
control. If you keep the context a singleton which does the appropriate
lock($myvar) things in the accessor methods on write access, there =
should
not be a problem. In a non threaded env lock() is a noop.

Also, there are quite a lot of interesting bits of Thread code on CPAN =
-
Thread::Pool maybe beeing the most interesting...

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Donnerstag, 7. November 2002 14:49
An: ope...@li...
Betreff: [Openinteract-dev] OpenInteract 2 issue


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

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



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm=20
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev