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

[Openinteract-dev] new packages available

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

Earlier today I posted to the sourceforge site [1] four new extra
packages. All four work with the newest version of OI -- in fact, you
can see them all (in some form or other) working at
http://www.ctaa.org/.

Two of them are fairly standard: 'event' and 'weblink' are community
calendar and link databases. Both use the OpenInteract::CommonHandler
module, which is a very easy way to build simple apps and even extend
them beyond simple.

One is standard with a twist: 'new_items' implements an "What's new?"
list, where participating object classes register new objects with
it. You can also add entries manually.

One is fairly new: 'object_link' implements a simple topic-based
linking scheme for objects. So you could relate a news story, event
and web page to a particular topic and be able to look up the other
two from any one. This sort of thing is the tip of the iceberg, I
hope.

All four are in CVS (under 'OpenInteract/extra_packages').

More extras are coming soon: a contact database, a shopping cart,
product database and simple order management. Good stuff.

Many kudos to intes.net for open-sourcing these modules. (Email Mark
Meszaros at ma...@in... with wondrous praise, if you're so
inclined.)

Thanks,

Chris

[1] http://sourceforge.net/projects/openinteract/

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

[Openinteract-dev] 'mkdir' in OpenInteract::Startup

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

Randal just pointed out to me that running under 5.005_03 you get an
error in OpenInteract::Startup:

---------------
Not enough arguments for mkdir at
/usr/lib/perl5/site_perl/5.005/OpenInteract/Startup.pm line 250, near
"$lib_dir )"
---------------

In 5.005x mkdir() takes two arguments (NAME, MASK) but in 5.6x the
second argument is optional, defaulting to 0777.

The fix is simple:

*** Startup.pm~	Wed Nov 28 00:55:07 2001
--- Startup.pm	Fri Nov 30 10:22:22 2001
----------------------------------------
*** 247,253 ****
      unshift @INC, $lib_dir;
  
      File::Path::rmtree( $lib_dir ) if ( -d $lib_dir );
!     mkdir( $lib_dir );
  
      my $site_repos = $REPOS_CLASS->fetch( undef,
                                            { directory => $base_config->{website_dir} } );
--- 247,253 ----
      unshift @INC, $lib_dir;
  
      File::Path::rmtree( $lib_dir ) if ( -d $lib_dir );
!     mkdir( $lib_dir, 0777 );
  
      my $site_repos = $REPOS_CLASS->fetch( undef,
                                            { directory => $base_config->{website_dir} } );
----------------------------------------

and has already been made in CVS. While the system won't run without
OpenInteract::Startup, I'm ambivalent about issuing a new release for
just this. What do you think?

Chris

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

[Openinteract-dev] axing the monster @INC

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

OpenInteract 1.30 and earlier use a fairly ugly hack to ensure all
modules are available to the webserver. When the server started up,
we'd call OpenInteract::Startup->main_initialize(). For each package
in the site we'd call OI::Startup->process_package(), and this in turn
added both the website package directory and the base installation
package directory to @INC.

With more packages being used, @INC gets pretty hefty -- print it out
from a handler sometime, ouch! There are some performance issues with
this, but they're not too relevant under mod_perl.

Recent changes to OpenInteract::ApacheStartup moved the
main_initialize() call from the server startup to the ChildInit
handler. And since you can't permanently modify @INC from anything
except PerlRequire/PerlModule, none of our modules were accessible.

My fix is to create at server startup a temporary library directory
and copy to it all relevant files from the website and base
installation directories. ('Relevant files' right now means anything
ending in '.pm', but that's easily fixed.)

Once created, we just add that single directory to @INC and we're
rolling. I've tested this out and it seems to work fine.

So my question (finally): does anyone see any issues with this?  The
only one I can think of is that there is some slight overhead copying
all the files at startup, but it's mimimal and probably offset (and
then some) by the overhead imposed by the old monster @INC.

Thanks,

Chris

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

Re: [Openinteract-dev] fetch_group and security

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

* Andreas Nolte (And...@Be...) [011128 03:04]:
> Hi Chris,
> 
> it took me a while to find out, why I exactly do not see this as the
> solution to all performance issues.
> 
> The problem arises, when you have a larger system ( right now we have
> 161.000 records in sys_security... ) and use ( maybe misuse ;-) ) the
> security system to provide for a multi client system where sys_security sort
> of works like some client row in a table.
> 
> In this setup you have queries, which return a larger result which gets
> boiled down within the security system to return only the records of one
> client. Therefore most fetches waste quite a lot of resources. Same thing
> with fetch_count...
> 
> What we will try is using sys_security whith skip_security like this:
> 
> call fetch_group with a join of the data table to sys_security on the
> relevant queries.
> 
> We hope, that this does it - more later.

Great! I'm very curious to hear the effects this has. Thanks for
braving the waters :-)

Chris

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

AW: [Openinteract-dev] fetch_group and security

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

Hi Chris,

it took me a while to find out, why I exactly do not see this as the
solution to all performance issues.

The problem arises, when you have a larger system ( right now we have
161.000 records in sys_security... ) and use ( maybe misuse ;-) ) the
security system to provide for a multi client system where sys_security =
sort
of works like some client row in a table.

In this setup you have queries, which return a larger result which gets
boiled down within the security system to return only the records of =
one
client. Therefore most fetches waste quite a lot of resources. Same =
thing
with fetch_count...

What we will try is using sys_security whith skip_security like this:

call fetch_group with a join of the data table to sys_security on the
relevant queries.

We hope, that this does it - more later.

regards,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Montag, 19. November 2001 14:05
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-dev] fetch_group and security

* Andreas Nolte (And...@Be...) [011119 03:12]:
> Hey!
>=20
> now that we have our first larger OI application running for a month
> or so ( a trouble ticket system ), we now look into optimizing
> it. What we found is, that checking security of a larger result set
> takes a significant amount of time - which is no suprize, really,
> but lead to looking into the SQL used.
>=20
> Right now, fetch_group works like this:
>=20
> - read all records controlled by the where clause and the limit ( 1
> query )
> - check security on each record ( 1 query for each record, so maybe
> thousands )
> - return only those records, for which security fits ( return maybe
> only 10.. )
>=20
> What I would like to discuss here, is if a join with sys_security
> wouldn`t make sense here.

It might not be a bad idea to make that option available. Similar to
how we generate the ID WHERE snippet with SPOPS::DBI->id_clause(), we
could generate a security clause as well. It would only work for
DBI-stored objects.

That said, I think the best thing to do (since it would work for all
SPOPS objects) is to cache the retrieved security values
instead. (This has been on my TODO list for a LONG time.)

This could work in a couple of ways. First, we could cache all results
of a security query for a particular object. Second, we could cache
the calculated level for a particular object and user.

These could actually run in tandem -- the first time an object is
requested we fetch *all* of its security information and put it in the
cache. Then we just use the cache to determine the security level for
a particular user and cache *that* value as well.

Queries for an object used in every request (like themes or groups)
would have a *huge* benefit, and objects viewed often (top ten news
items, whatever) would as well.

We'd have to have a way to expire entries from the cache when security
is changed for a particular object as well. (This is important but
probably not critical since in most environments security would be
changed rarely on a particular object.)

I need to get the next versions of everything out and work on the
modified object relationship specifications. But caching is moving up
the TODO list.

Later,

Chris

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

[Openinteract-dev] Re: SPOPS-0.53 and cloning

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

* Ray Zimmerman (rz...@co...) [011126 10:53]:
> Chris,
> 
> It looks like there's been a change in the behavior of clone from 
> 0.52 to 0.53. Previously it was possible to do ...
> 
> 	$obj1 = MyClass->fetch($id);
> 	$obj2 = $obj1->clone;
> 	$obj2->save;
> 
> ... with no problems since the call to clone would set the id to 
> undef in the clone. With SPOPS-0.53, the id is copied as well so the 
> save attempts an insert and fails with duplicate key problems.
> 
> Bug or feature?

Bug -- I tried to mix multifield checks in there and failed. The
previous behavior has been restored in CVS, and an updated version
will be out shortly.

The tests didn't catch this because they don't use auto-generated
keys. I might fix this in the future, but that's fairly low on my
list. (It would probably come with porting the SQLInstall stuff from
OpenInteract to SPOPS...)

Thanks much for the clear report.

Chris

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

[Openinteract-dev] SPOPS-0.53 and cloning

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

Chris,

It looks like there's been a change in the behavior of clone from 
0.52 to 0.53. Previously it was possible to do ...

	$obj1 = MyClass->fetch($id);
	$obj2 = $obj1->clone;
	$obj2->save;

... with no problems since the call to clone would set the id to 
undef in the clone. With SPOPS-0.53, the id is copied as well so the 
save attempts an insert and fails with duplicate key problems.

Bug or feature?

-- 
  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 error handling

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

* Ray Zimmerman (rz...@co...) [011022 09:32]:
> Chris,
> 
> For the error handling in our apps we've decided to use a sub-class 
> of the Error class (as in Error.pm from CPAN) and just do something 
> like ...
> 
> 	die new My::Error('message', $other, $error, $info)
> 
> ... where the constructor for My::Error records the stack trace, etc, 
> and then use an eval block and "if ($@)" to catch it elsewhere. In 
> the "if ($@)" part we can handle different types of error objects 
> differently if desired.
> 
> We'd like to be able to handle our SPOPS errors in the same 
> framework, but it isn't quite as clean as we'd like. Since an SPOPS 
> error dies with a string, we have to somehow determine from that 
> string whether it was SPOPS that died or something else (not sure how 
> to do this), then, if it was SPOPS, go get the info from the SPOPS 
> error variables.
> 
> So, I was wondering, why do you use the "put the error info into some 
> error variables and die with a string" approach rather than "put the 
> error info into an object and die with that object" approach to error 
> handling in SPOPS?  Maybe there is an advantage I don't see. And the 
> follow-on question, in case it turns out the latter is more desirable 
> ... would you consider changing it?

I'm including this entire message rather than snipping because it was
sent a month ago. Since I just released 0.53 I'm thinking about the
next version. I'd like to start working on this not only for the
reasons Ray mentions above, but also because some of the discussion on
the P5EE mailing list [1] has led me to think throwing exceptions is a
smart way to do error handling.

Rather than reinvent the wheel (for which I have an unfortunate but
admitted tendency), I figured a good place to start would be the
Exception::Class module. Dave Rolsky has been using it for a while
with Alzabo and other projects with success, plus it's used in the
libservlet API [2] and will probably be used as a core component in
the P5EE effort.

One of the attractive side-effects of this effort will be cleaner
error handling -- most exception frameworks allow only a message to be
associate with an exception, since the type of exception itself
reveals much about the error encountered.

So pop up if you have any opinions or questions about this.

Thanks,

Chris

[1] P5EE mailing list and info - http://p5ee.perl.org/
[2] libservlet - http://sourceforge.net/projects/libservlet/

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

Re: [Openinteract-dev] Umlaut characters with LDAP

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

* Andreas Nolte (And...@Be...) [011120 15:15]:
>  .. yes it does. So I learn OI rules now... ;-)

Heh. I can give you a head start, and you can be a test subject :-)
I'll send you a sample shortly.

Chris

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

RE: [Openinteract-dev] Umlaut characters with LDAP

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

 .. yes it does. So I learn OI rules now... ;-)

later,

Andreas

-----Original Message-----
From: Chris Winters
To: ope...@li...
Sent: 20.11.01 19:44
Subject: Re: [Openinteract-dev] Umlaut characters with LDAP

* Andreas Nolte (And...@Be...) [011120 12:40]:
> Hey!
> 
> one small problem we have with SPOPS::LDAP is, that character values
are not
> converted from UTF8 unicode, which LDAP uses to ASCII and viceversa.
English
> writing people do not recognize this, but e.g. we Germans see funny
> characters.
> 
> Anyway: the conversion is actually easily achieved: 
> 
> use utf8; # somewhere
> 
> and to this transform when reading from LDAP
> $thevalue =~ tr/\0-\x{FF}//UC;
> 
> and this when writing to LDAP or before sending passwords out to
check.
> 
>  $thevalue =~  tr/\0-\xFF//CU;  
> 
> Now the question: where should these transform be made in a "good
world" ;-)
> ? In SPOPS::LDAP ?

Good question. My knowledge of these sorts of things (unicode, utf8,
etc.) can fill a thimble. Are there any penalties for 'use utf8'?
Would we want to make this an option for people that particular fields
need to be transformed in the method that you described?

This would be fairly easy to implement -- in fact, maybe what we can
do is create SPOPS rules for doing this. So you'd specify in your
object configuration the fields that need to be converted and we'd
have a post-fetch that would do the first conversion and a pre-save
that would do the second. (Password checks and other custom usages
would need to call a method to do the conversion.)

Does that sound reasonable?

Chris

_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] Umlaut characters with LDAP

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

* Andreas Nolte (And...@Be...) [011120 12:40]:
> Hey!
> 
> one small problem we have with SPOPS::LDAP is, that character values are not
> converted from UTF8 unicode, which LDAP uses to ASCII and viceversa. English
> writing people do not recognize this, but e.g. we Germans see funny
> characters.
> 
> Anyway: the conversion is actually easily achieved: 
> 
> use utf8; # somewhere
> 
> and to this transform when reading from LDAP
> $thevalue =~ tr/\0-\x{FF}//UC;
> 
> and this when writing to LDAP or before sending passwords out to check.
> 
>  $thevalue =~  tr/\0-\xFF//CU;  
> 
> Now the question: where should these transform be made in a "good world" ;-)
> ? In SPOPS::LDAP ?

Good question. My knowledge of these sorts of things (unicode, utf8,
etc.) can fill a thimble. Are there any penalties for 'use utf8'?
Would we want to make this an option for people that particular fields
need to be transformed in the method that you described?

This would be fairly easy to implement -- in fact, maybe what we can
do is create SPOPS rules for doing this. So you'd specify in your
object configuration the fields that need to be converted and we'd
have a post-fetch that would do the first conversion and a pre-save
that would do the second. (Password checks and other custom usages
would need to call a method to do the conversion.)

Does that sound reasonable?

Chris

[Openinteract-dev] Umlaut characters with LDAP

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

Hey!

one small problem we have with SPOPS::LDAP is, that character values are not
converted from UTF8 unicode, which LDAP uses to ASCII and viceversa. English
writing people do not recognize this, but e.g. we Germans see funny
characters.

Anyway: the conversion is actually easily achieved: 

use utf8; # somewhere

and to this transform when reading from LDAP
$thevalue =~ tr/\0-\x{FF}//UC;

and this when writing to LDAP or before sending passwords out to check.

 $thevalue =~  tr/\0-\xFF//CU;  

Now the question: where should these transform be made in a "good world" ;-)
? In SPOPS::LDAP ?

later,

Andreas

[Openinteract-dev] Re: [Openinteract-help] user-in-group

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

* Jochen Lillich (jl...@te...) [011119 10:45]:
> Which is the fastest way of finding out if user X is in group Y? I
> didn't find a ready-to-use function.

Good question. It would probably be a good idea to make this part of
the user class. In OpenInteract we can do something like (untested):

sub is_in_group {
    my ( $self, $group_spec ) = @_;
    my $check_group_id = ( ref $group_spec )
                           ? $group_spec->id : $group_spec;
    foreach my $group ( @{ $R->{auth}{group} } ) {
        return 1 if ( $group->id == $check_group_id );
    }
    return undef;
}

I'll probably stick this into base_user before the next OI release.

As a sidenote, I've been thinking it would probably be a good idea to
make most (if not all) of the functionality of $R available through
methods rather than through direct hash accesses. So the above might
look something like:

    foreach my $group ( $R->login_group ) {

instead. We'll see how this goes...

Chris

Re: [Openinteract-dev] Re: fetch_group and security

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

* Jochen Lillich (ge...@li...) [011119 10:39]:
> I'd second that. Lately, I used fetch_count and then spent quite
> some time finding out why my page would take half a minute to
> display. The answer was simple: fetch_count retrieved every single
> record of about 2.000, checked security and went on to the
> next. That makes fetch_count unusable in this situation.

Good point. The solution I mentioned with asking the object to
generate a clause for the join seems appropriate here as
well. Something like this will probably go in version 0.54 -- 0.53 is
pretty much ready to go and I want to get it out.

Chris

[Openinteract-dev] Re: fetch_group and security

[Jochen L. <ge...@li...>]

Andreas Nolte schrieb am Mon, 19 Nov 2001 09:02:29 +0100:

> What I would like to discuss here, is if a join with sys_security wouldn`t
> make sense here. 

I'd second that. Lately, I used fetch_count and then spent quite some
time finding out why my page would take half a minute to display. The
answer was simple: fetch_count retrieved every single record of about
2.000, checked security and went on to the next. That makes fetch_count
unusable in this situation.

Regards,

        Jochen

-- 
Jochen Lillich                  http://geewiz.teamlinux.de

$ rm -rf /bin/laden

Re: [Openinteract-dev] fetch_group and security

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

* Andreas Nolte (And...@Be...) [011119 03:12]:
> Hey!
> 
> now that we have our first larger OI application running for a month
> or so ( a trouble ticket system ), we now look into optimizing
> it. What we found is, that checking security of a larger result set
> takes a significant amount of time - which is no suprize, really,
> but lead to looking into the SQL used.
> 
> Right now, fetch_group works like this:
> 
> - read all records controlled by the where clause and the limit ( 1
> query )
> - check security on each record ( 1 query for each record, so maybe
> thousands )
> - return only those records, for which security fits ( return maybe
> only 10.. )
> 
> What I would like to discuss here, is if a join with sys_security
> wouldn`t make sense here.

It might not be a bad idea to make that option available. Similar to
how we generate the ID WHERE snippet with SPOPS::DBI->id_clause(), we
could generate a security clause as well. It would only work for
DBI-stored objects.

That said, I think the best thing to do (since it would work for all
SPOPS objects) is to cache the retrieved security values
instead. (This has been on my TODO list for a LONG time.)

This could work in a couple of ways. First, we could cache all results
of a security query for a particular object. Second, we could cache
the calculated level for a particular object and user.

These could actually run in tandem -- the first time an object is
requested we fetch *all* of its security information and put it in the
cache. Then we just use the cache to determine the security level for
a particular user and cache *that* value as well.

Queries for an object used in every request (like themes or groups)
would have a *huge* benefit, and objects viewed often (top ten news
items, whatever) would as well.

We'd have to have a way to expire entries from the cache when security
is changed for a particular object as well. (This is important but
probably not critical since in most environments security would be
changed rarely on a particular object.)

I need to get the next versions of everything out and work on the
modified object relationship specifications. But caching is moving up
the TODO list.

Later,

Chris

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

[Openinteract-dev] fetch_group and security

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

Hey!

now that we have our first larger OI application running for a month or so (
a trouble ticket system ), we now look into optimizing it. What we found is,
that checking security of a larger result set takes a significant amount of
time - which is no suprize, really, but lead to looking into the SQL used. 

Right now, fetch_group works like this:

- read all records controlled by the where clause and the limit ( 1 query )
- check security on each record ( 1 query for each record, so maybe
thousands )
- return only those records, for which security fits ( return maybe only
10.. )

What I would like to discuss here, is if a join with sys_security wouldn`t
make sense here. 

Comments?

regards,

Andreas

[Openinteract-dev] [JOB] OpenInteract developer wanted

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

A company I've been working with asked me to post this job. You'd be
working with a substantial (and growing!) OpenInteract system that I
designed and built, which could be a plus or a minus depending on how
you look at it :-) Feel free to ask me for details.

Chris

----------------------------------------

URL with full description: http://jobs.perl.org/job/97

Location: (USA) Pittsburgh, Pennsylvania

Hours: Full-time, onsite

Description:

This position will join a team responsible for the development and
maintenance of an interactive data management system for internal
use. Position requires significant experience with intranet
development using OpenInteract, HTML, Perl, SQL, and
Apache/mod_perl. DB2 on AS/400 is also desired. Experience in a
Win32 environment needed with possible Linux migration.

Knowledge/Experience:

BA/BS with minimum 4 years progressively responsible experience within
administrative computing environment; demonstrated experience on a
technical team; excellent analytical skills; detailed knowledge of
database design and relational technology with demonstrable mastery

Experience with OpenInteract, Template Toolkit, SQL, Perl and
programmatically generated HTML very highly desired. Also:
Apache/mod_perl administration, knowledge of MySQL and IBM DB2 on
AS/400, C/C++, thin client or web driven applications development
experience.

Contact information:

To apply or for information, send resume, salary requirements,
references and a sample of your work (a small web-dbi script or
something) to Per...@bi...

No 3rd Parties please. Only US Citizens or authorized to Work for any
employer in the US.

P.S. Recruiters are 3rd parties, see above.

[Openinteract-dev] read-only objects in SPOPS

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

For some reason this crossed my mind recently and I was curious how
easily I could make an object read-only in SPOPS. Very easily, it
turns out :-)

----------------------------------------
package My::ReadOnly;

# $Id: ReadOnly.pm,v 1.1 2001/11/09 04:36:49 lachoy Exp $

use strict;
use SPOPS               qw( _w DEBUG );
use SPOPS::ClassFactory qw( OK );

sub behavior_factory {
    my ( $class ) = @_;
    DEBUG && _w( 1, "Installing read-only persistence methods for ($class)" );
    return { read_code => \&generate_persistence_methods };
}

sub generate_persistence_methods {
    my ( $class ) = @_;
    DEBUG && _w( 1, "Generating read-only save() and remove() for ($class)" );
    no strict 'refs';
    *{ "${class}::save" }   = 
          sub { warn ref $_[0], " is read-only; no changes allowed\n" };
    *{ "${class}::remove" } =
          sub { warn ref $_[0], " is read-only; no changes allowed\n" };
    return OK;
}

1;
----------------------------------------

To use, put 'My::ReadOnly' in the 'rules_from' of your object
configuration. Cool :-)

This will be in the eg/ directory of the next SPOPS release.

Chris

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

[Openinteract-dev] Re: [Openinteract-help] Multifield values for database storage?

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

* Terrence Brannon (bl...@sv...) [011105 00:47]:
> i havent dealt with it in awhile. Jswartz, who is using Class::DBI, 
> might be able to chime in with some input.
> 
> my first thought on the subject is that Storable uses a binary format 
> for storage , so a BLOB field in a database might work... just a thought.

Sure, that's one way. And in fact this would be pretty simple to
implement now using the method I mentioned in the previous email.

> the other obvious thing is to store several rows per object, one row
> per array element.

Sure. It might be interesting to code this using the pre-save and
post-fetch methodology I mentioned earlier. You might be interested to
poke around a bit with ESPOPS, which is at:

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

This work will be folded into SPOPS in the hopefully near future.

Chris

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

[Openinteract-dev] Re: [Openinteract-help] Multifield values for database storage?

[Terrence B. <bl...@sv...>]

On Sunday, November 4, 2001, at 09:28 PM, Chris Winters wrote:

> * Terrence Brannon (bl...@sv...) [011104 15:30]:
>> SPOPS::Manual::Object does not state that multivalued fields are
>> emulated for databases... does it emulate them?
>
> Nope. Multivalued fields are relatively new and are only implemented
> in the LDAP datastore right now.
>
>> If not, what are we supposed to do when using CGI.pm and we get back
>> a param() which returns us an array ref?
>
> Good question. How do you deal with it now?

i havent dealt with it in awhile. Jswartz, who is using Class::DBI, 
might be able to chime in with some input.

my first thought on the subject is that Storable uses a binary format 
for storage , so a BLOB field in a database might work... just a thought.

the other obvious thing is to store several rows per object, one row per 
array element.

[Openinteract-dev] Re: [Openinteract-help] Multifield values for database storage?

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

* Terrence Brannon (bl...@sv...) [011104 15:30]:
> SPOPS::Manual::Object does not state that multivalued fields are
> emulated for databases... does it emulate them?

Nope. Multivalued fields are relatively new and are only implemented
in the LDAP datastore right now.

> If not, what are we supposed to do when using CGI.pm and we get back
> a param() which returns us an array ref? 

Good question. How do you deal with it now?

> How can we store this transparently in a SPOPS object which goes to
> a database storage technology?

I haven't had to deal with it yet so it's not in there. It seems there
are several different ways to handle this. For instance, if the list
of items doesn't have any dependencies outside the object and/or
table, you could create a pre-save action which serializes the values
using Data::Dumper (or even just using 'join') and create a post-fetch
action which unserializes them. Neat, simple and transparent. But
usually the task at hand is more complicated.

Future relationship modifications should make it possible to deal with
this transparently when the objects are in different tables. So you
could access a list of dependent objects as a property of the object
rather than calling a method to fetch them. If you're interested in
this, check a post from Ray Zimmerman in the openinteract-dev mailing
list from June/July of this year.

Chris

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

[Openinteract-dev] SPOPS multiple field keys, part 2

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

So after thinking about this problem of multiple-field primary keys
for a while, I came up with what seems to be a decent solution. I'm
still testing it out, but it seems to work well and I wanted to see if
anyone had any thoughts before I charged ahead.


First, I believe that the ID of an object should be a string or easily
stringified. This is not only for us people who like to read such
things, but SPOPS does a lot of work (security, for one) using the
object class and ID value. (Caching will be the same way.)

So with that in mind, here's some demo code:


 # This object uses three fields (field1, field2, field3) for the key,
 # and we delimit the values with commas to make a single string. We
 # will probably make the delimiter customizable.

 my $id = join( ',', $field1, $field2, $field3 );
 my $obj = My::MultiFieldKey->fetch( $id );

 # Retrieve the ID in scalar context:
 
 print "ID: (", scalar $obj->id, ")";

 # >> ID: (45,99,ABCD)

 # Now retrieve the ID in list context

 my @val = $obj->id;

 # Values: $val[0] = 45; $val[1] = 99; $val[2] = 'ABCD';

 # Display the SQL clause we use to uniquely retrieve, update and
 # remove this record

 print "WHERE ", $obj->id_clause;

 # >> WHERE table.field1 = 45 AND table.field2 = 99 AND \
 #    table.field3 = 'ABCD'

 # Get the ID fields in scalar context

 print "ID fields for object: ", scalar $obj->id_field, "\n";

 # >> field1,field2,field3

 # Get the ID fields in list context

 my @to_select = map { "$table.$_" }, @selected, $obj->id_field;



What you need to do:

 - Specify the ID fields you want in your object configuration as an
arrayref instead of a string:

  id_field => [ 'field1', 'field2', 'field3' ]

That's it! 


Caveats:

 - You must always keep the ordering of the fields listed in
 'id_field' of your configuration, or you'll break security and other
 object layers (full-text indexing, etc.).

 - You can link to objects in this class, but you can't use the
 'has_a' type of relationship

 - I need to look at and modify something in the lazy loading
 implementation for SPOPS::DBI

 - If part of your multifield key is automatically generated (using a
 pre/post_id method such as with auto-increment/sequenced fields),
 then there *might* be some issues, but it will probably work fine.


How it works:

Two new class-factory behaviors in SPOPS::DBI treat an arrayref in the
'id_field' of a class configuration as a signal to generate the
methods:

  id_field()
  id()
  id_clause()


These are created at startup for a multiple field class, and then it's
just like every other class. There are no modifications to the class
hierarchy or anything else. (And classes using a single field for an
ID aren't touched.)

So I need to test this out some more and see how it works -- nothing
like testing on live data! -- but if you have any ideas I'd love to
hear them. I feel like there's something I'm missing....

Chris

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

[Openinteract-dev] multiple-field primary keys in SPOPS

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

I've come across a problem that would seem to require me to use
multiple-field primary keys. (Legacy system, don't ask.)  And, of
course, it would be nice if SPOPS supported this not only for my needs
but also for general situations where others have to support poorly
designed databases.... I hope to be able to deal with this relatively
soon so I don't pull *all* the hairs out of my head.

This email is just kind of a ping out there to see if anyone has done
this before and has sage words of wisdom, things to watch out for,
etc. 

So: *ping*

Chris

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

Re: [Openinteract-dev] Using packages

[Drew T. <dr...@dr...>]

At 10:02 PM 10/29/2001 -0500, Chris Winters wrote:
>* Drew Taylor (dr...@dr...) [011029 21:38]:
> > Hmmm, things seem to be working now. I restarted Apache a couple of
> > times, but I swear I did that before sending this post. Anyway, I'm
> > off to dissect the News and Classified modules so I can see how
> > things are done.
>
>I was actually just getting ready to reply with this -- you have to
>stop Apache, then restart it. SPOPS doesn't play well with a -HUP
>restart. I was going to say it's in the FAQ, but it's not. (It will be
>in a second tho...)

I wondered about that. Makes sense nowe. Before I used "apachectl restart", 
which does a HUP. SPOPS isn't the only thing that doesn't like a HUP very 
much. When it started working, I did a stop and start. I was used to the 
init.d script that did a full stop and start. One more mental note to file 
away...

>It's in base_theme/template/base_main.tmpl -- but you can change
>this by editing the theme and setting the 'main_template'
>property. This should be in a 'package::name' format, unless you put
>the template in the $WEBSITE/template directory, in which case you can
>just use 'name'.
>
>I plan to make this location for the main template (and the 'simple'
>template) the default in the future -- it's more intuitive.

Ahhh, the one place I didn't look! Thanks. That makes sense now. I've found 
the template.

> > Thanks for an awesome framework Chris! I look forward to delving
> > into OI applications.
>
>Thanks! I look forward to seeing them :-)

Well, I just first have to figure out the first itch to scratch. Perhaps I 
need to replace my PHP image gallery with a perl one. :-) If anyone has 
ideas for generic reusable components, I'm listening. I'm still looking for 
a job, so unfortunately I have some time on my hands. :-(


Drew Taylor                     JA[P|m_p|SQL]H
http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker
mailto:dr...@dr...      *** God bless America! ***
ICQ: 135298242