From: Chris W. <ch...@cw...> - 2003-05-14 03:34:57
|
Steve Sapovits wrote: > I brought this topic up a while ago here. Chris gave me some > starting pointers which I sat on while I caught up on my "real" > work. I recently had some time to get back to this. Here's my > current dilemma: Sorry for the delay in responding. This got put in my: "think about it for a while" queue, which can take a little while to flush... > We have a package that we use for data transforms that allows you > to configure a set of inputs/filters/outputs. Basically you build > a map defining all the steps. Once you have a map you can either > feed it to a translator, which runs the whole thing; or you can fetch > a row from an output node and do what you want with that row. There > are no row level IDs used here -- if you're fetching, you just fetch > the next row until there are no more. SPOPS, being more of a table > model, wants IDs for fetches. Is there a way around this? I'm not exactly clear on the inputs/filters/outputs implementation. If you're retrieving one row at a time then yes, you need to either fetch by ID or create a method to do the fetch for you. (There's a shortcut SPOPS gives you with the 'fetch_by' configuration directive, but that always returns an arrayref (unless you specify the 'return_single' parameter, but that's kind of ugly).) If the inputs/filters/outputs creates a query then 'fetch_group()' will retrieve a number of objects for you all at once, putting them in an arrayref. And, probably more appropriate, 'fetch_iterator()' takes the same parameters as 'fetch_group()' but returns a lazy-loading iterator from which you can kick out your objects one at a time. > Looking at > what we have, it's really more suitable as a template level tool maybe; > i.e., just give it a wrapper and expand the data sets using TT constructs. > But I'd like to utilize the security layer SPOPS offers for data access. In theory you can use SPOPS security without using anything else from SPOPS. As long as you can identify your objects uniquely with a class (or general object type) and a unique-to-that-class ID, you should be able to get and set security levels. It's probably not the most efficient means for doing this, but it would work. > And, since we do use this for canned data writes/updates, I want to keep > an eye on plugging this in more fully as a full data access layer. In all > cases where I'd be using this now (read only), I'd be fetching the entire > set of data the translation defines, although I will want to be able to > segment larger sets so they can be paged. In OI this is done with the 'results_manage' package. (It's not optimal, but it works everywhere.) > Just using implicit sequence > numbers seems to fit. It's not clear to me how far up the need for an > ID bubbles though ... assigning my own would not give higher level users > any universally known key (like a user name, etc.). What sort of usage > impact does that have within the entire OI framework? I'm not exactly sure what you're getting at. OI doesn't really care what form your ID takes, just as long as it's unique. From the OI/SPOPS view there's nothing technically wrong with having an ID of 'email' for a 'users' table. And I'm 98% certain the ID you specify in SPOPS doesn't even have to be the field the database recognizes as the primary key -- if in that same 'users' table you had a sequenced ID field, SPOPS wouldn't really care as long as it was self-maintaining (with a trigger/sequence/generator or IDENTITY/auto-increment field) and you told SPOPS never to insert any data for it. > Also, regarding the paging need, I'd want to not be required to load the > entire set in since some of these can be quite large. Load as needed is > mostly the model I'd want. The 'fetch_iterator()' does this fairly well, I think. And you can standardize on using it in TT (or other views) since even when you have a list of objects you can use SPOPS::Iterator::WrapList to present a common interface. I feel like I'm missing the point of what you're really asking though. Maybe you can present a small example? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |