Re: [Openinteract-help] lc and searching

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

On Jan 5, 2004, at 7:06 AM, Vsevolod (Simon) Ilyushchenko wrote:
>> Where is this giving you a problem? I probably did this to ensure 
>> that everything was handled consistently internally.
>
> It happens once in SPOPS::Tool::DBI::DiscoverField and a whopping
> eight times :) in SPOPS::Tie.

Arg! I hate tie! It's caused nothing but pain!

Seriously, if we didn't lc the fieldnames in the tie implementation 
we'd be in a world of hurt -- is this field loaded, is this field 
changed, and similar checks would be more error prone. But these should 
be encapsulated in the tie implementation and I'm not sure why you'd 
care about them.

> The script is cool (I did not know you could do that :), but my 
> problem is similar to your Pittsburgh example. My code looks similar. 
> But if the definition of Person has_a Address, it feels redundant to 
> specify the "person.address_id = address.address_id" clause. (And the 
> clauses for links_to classes are even bulkier.)
>
> I wish I could just automagically say
>   my $people = Person->fetch_group({
>     where => "city = 'Pittsburg'});

You're right, you should be able to do that.

> Of course, if more than one dependent class of Person has the 'city' 
> field, there has to be a way of choosing the one we need. Perhaps it 
> can be prefixed: "address.city='Pittsburg'", where "address" is not 
> the name of the table with addresses, but the alias of the address_id 
> field in Person. Then the table structure is nicely abstracted away. 
> :)

Yeah, that's what my idea was too. The only problem with this is we're 
treading dangerously close into parsing and I really don't want to do 
that.
I guess we can keep it simple and pull out all the foo.bar strings, see 
if 'foo' is an alias and if so add the proper linking clause. (We do 
this in OpenInteract::Common and OpenInteract2::Action::CommonSearch to 
build search queries.)

> I saw the note by Ray Zimmerman mentioned in your documentation and 
> already ran into some of its issues with the order of saving of the 
> contained classes (for a new object, the has_to classes have to be 
> saved first, then their ids should be given to the top-level object, 
> then this object should be saved, then its id should be used to save 
> the links_to objects).

Right... I want to make this lazy (that is, not evaluate ID fields and 
the like at generate time) and therefore not require any processing 
order.

> After I get a bit more familiar with SPOPS, let me know if I can give 
> you a hand with this.

Be careful what you wish for :-)

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988