Re: [Openinteract-help] getting started

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

On Mon, 2002-11-18 at 09:57, Steve Sapovits wrote:
> This gives me something more to chew on.  Let me throw some more specifics
> at you.  We have many existing data stores I'd want to feed up through OI
> and its TT front end.  A lot of these are Oracle databases/tables.  Those
> are managed by existing apps., but it would seem I could plug those in as
> read only and still benefit from the full OI stack (security, access, etc.).
> I didn't see any master read-only flag -- just a setting that lists the
> columns that are not to be updated.  Is that correct?  For read-only, are
> there advantages to going full OI versus doing something like you suggest
> above?

Actually, SPOPS has a tool for this. If you add: SPOPS::Tool::ReadOnly
to your object's isa declaration, like:

my $spops = {
   myobject => {
      class => 'This::Object',
      isa   => [ qw/ SPOPS::Tool::ReadOnly OpenInteract::SPOPS::DBI
                     SPOPS::DBI::MySQL  SPOPS::DBI / ],
      ...
   },
};

Then any calls to save/remove get intercepted into a no-op.

> In addition to the DB tables we have this other data translation tool set.
> That can either work off DB tables or other data stores; and it creates
> non-database stores (e.g., files in various formats) we'd want to display.
> It would seem one way to do this would be to create an SPOPS interface to
> our data tool set -- fill in enough of the methods to have data accessed
> read-only.  It has a well-defined interface so I think this might be
> relatively easy.  I'm just not 100% clear on the benefits of doing that
> versus just using a direct TT interface to that data.

There's not much of a benefit. If you were creating tools for other
people to use it would be useful, but if it's for an in-house project
(or set of projects) there's not much use beyond being consistent with
what OI currently uses. That you're probably already used to using your
interface overrides any benefit OI would have.

> One other question I haven't seen answered:  For large data driven tables,
> what's the procedure for having those displayed paged?  I know TT offers
> something here, but does OI do anything more?  Do you have to load a full
> table set for each access and page into it, or is there something better?

Yes -- check out the 'results_manage' package; specifically
OpenInteract::ResultsManage. What happens is that your query will fetch
all the IDs the first time; these are stored in a temporary file keyed
to a value which you use as a search ID. Then you pass in the search ID,
the number of items per page and the page number and you'll get in
return an iterator which will cycle through those objects.

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