Hi,

I thought that the basic things from Links SQL and Links 2.0 were the same, but the search.cgi files work differently, and this is a real bad thing for me right now, which is what most of my site will run off

With Links 2.0, if for example I had a field called space and one of them had a value of 30MB I could use this.

search.cgi?space=30MB

and I would get a result.

With SQL if I try one (that I know exists)

search.cgi?controlpanel=Yes

I just get redirected to the search form

http://www.webhostarea.com/cgi-bin/hosts/search.cgi?controlpanel=Yes

Is the full thing, I haven't made the actual form yet, I have been typing in the URL's.. please advice, this is sorta urgent.

Thanks in advance BTW (Please don't say mod the code, I would have done that if I could, but after looking at the search.cgi file gave up on this).

------------------
Michael Bray
....
Review your webhost, or find a new one at http://www.webhostarea.com

It does support what you ask (somewhat). You must always pass in query=something, but can filter the results. i.e. to search for a link that matches 'somestring' and is new, you could do:

search.cgi?query=something&isNew=Yes

Hope this helps,

Alex

Alex:

To clear up some fine points:


This means, that the search.cgi looks for a passed parameter query to act on (the same way jump.cgi looks for ID).

You can add options to that query, using the standard "&" notation and form input.

Do we need to write the utils to parse that out?? Or is it parsed out for us and put into the in-> array?

We then only need to add a line to the top of the file:



It looks like it would work, but we already found out that search does things its own way.






------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

could you do

query=*

?

jerry

 
All form input is automagically put into $in and can be acccessed normally. Also, search.cgi recognizes if you pass in a field_name=somevalue and adds that to the filter list to filter the results from.


No, that would make things to easy. Unfortunately the way the filter works, is it needs a result set to work against, and it would be very impractical to grab the whole list of links first. You could hack this in though. If you do something like:

search.cgi?custom=1&field_name=somevalue

then in search.cgi:

if ($in->param('custom')) {
$hits = $db->query ( { field_name = $in->param('field_name') } );
...
}

details left to the reader, but I hope you get the idea.

Cheers,

Alex

Great -- So it works the way you'd expect

Once the holidays are over, I think great things are going to be shown off by the various sites that have started to get the modifications working.

------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

that means he has to turn off is_db_indexed..

or at least mod query to say either on or off.. just like with substring..

jerry

Thanks Jerry,

I was writing a message joking about you ignoring me when I got the message saying you had responded. Thanks mate, appreciated!!!!

alex..

do you really have to check query twice??

first you check it in sub main.. then in sub search..

can't you eliminate this code..


and michael.. i change my mind about that code it wouldn't work anywhere in search.cgi but it was to let you know about the filter thing..

and .. please try

http://www.url.com/...amp;controlpanel=Yes

i don't see why that wouldn't work and in the admin it allows ID=*

jerry

Jerry, you get this error if you try it..


I am gonna have a look through search.cgi see if I can delete the ckecking for this...

nope.. it's DBSQL.pm

i just noticed it.. it doesn't allow the query to be * but allows for fields to be *..

grr...

ok.. you're gonna have to go another way..

change


to


delete this line


under:


add..


now try it.. if it gives some error about query..

change this line:


to


jerry

and DUH..

http://www.url.com/...amp;controlpanel=Yes

if you don't respond.. i don't sleep..

i'm gonna have to readjust my sleeping and waking up times back to normal some day..

jerry

that wasn't a promise you know..

anyways.. i'll check back on you tommorrow..

probably late after noon when i wake up..

jerry

Will test in 30 mins, in the middle of a movie, just checking up while the ads are one

OK then, no error messages, but I have made it with links the controlpanel attribute has to be either Yes or No, and either way I don't get any results

I'll work on this while you guys in the northen hemisphere sleep :P

Hmmm.. It doesn't work when I search for ID=3 etc - Is there a variable somewhere like in Links 2.0 where I have to choose the fields to be searched? Thanks!

In your .def file, did you set the weight of the ID field to '1' ??

The search.cgi only searches fields that are indexed, and only fields with a weight>1 are indexed.

Could someone please explain how I would place that for more then one object.. example.. would I place it like...


Also, do I place in in sub search, or by itself?

THANKS!

once the holidays are over.. i have to study for finals ..

also.. pugdog.. will you please email me.. i can't find your email anywhere..

jerry

oh. i totally ignored you michael

no.. not foreach..


once again.. alex can't he just say.. ?query=*&field=links

or something..

Ok, there are two modes of searching: indexed and normal. To search with the search index, you should use:

$db->query ( { index => 'some phrase', filter => \%filter } );

This allows you to use altavista style searching with +, - , "phrases", etc. The search index requires something to be entered in the index part, and the filters only work on filtering the result of your search. Also, the search index does not allow you to search on *.

The second method of searching, is by just passing in field names to query. This is how the admin works:

$db->query ( { Title => "foo", Description => "bar" } );

With this, you can use * to match all fields, but you can't use altavista style searching. So, if you don't want to use the search index, and just search on a field like the admin, you have to use this second search method. That's why you want to do something like:

if ($in->param('query')) {
.. do search as normal with indexed search
}
elsif ($in->param('custom')) {
.. use second style of searching like admin
}
else {
.. oops, no search terms entered. display form.
}

The second method would look just like:

my $hits = $db->query (&cgi_to_hash($in));

and assuming you have passed in Field_name=Somevalue to the form, it will do a search just like the admin.

I hope this helps,

Alex

eck.. so he has to make another sub..

he can still use filter though.. but not the same way.. more like


no substring..

jerry

wait a sec.. michael... follow my instructions above again.. do everything excecpt the last one..

do this instead..


jerry

It works! Thanks Jerry, Alex and Pugdog!

http://www.webhostarea.com/cgi-bin/hosts/search.cgi?custom=1&ID=2

Now I just need to fix up the templates so you know what everything is :P

wow..

that "might" be useful for me.. tell me if you can ever get the range searches to work.. like < 50 megs.. i need to do something like that except with price

thanks alex for the clues.. i bet you knew how to do it since the beginning.. helping us learn or something?

jerry