Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Changes to Search Routines

Quote Reply
Changes to Search Routines
To pull this to a top level discussion, Alex had asked:

Quote:

One change I was thinking to making to the searches, is normally Links groups by category and returns result by
category name ascending. This really favours results that are in category's that start with a,b,c etc.

How about if we switch to always returning results by score, and then just group the links together by category on a
page. So on page one, you'd have the top 20 matches, but they would be grouped together by category. This means
on page 2 you might have a link in a category that has already appeared in page 1?

Personally, I would like to see links add the category name (linked and short) to the %globals array availabilty when links builds the <linkresults> list.

This way, results can be sorted by score, category, title, etc, and it allows links that are listed by score or title, to have their associated category listed in whatever format the links owner wants -- above the link, at the end of the link in a "more like.." field, etc.

Alex has already built in support for altering the way search results are returned on the various forms (THANKS!), and dynamic page creation promises (maybe?) to allow the user to set preferences on how results are returned, the look of the page, etc.

But, with more flexibility comes more effort on the webmasters part to make sure the forms view correctly in different layouts and preferences.

Quote Reply
Re: Changes to Search Routines In reply to
Hmm, Do you mean you want different templates for what a link looks like? Like a link_search.html as well as a link.html? Or do you just want the category name available as a tag in link.html?

One of the nice things with how it is now, is that if you want to change how a link looks, you only have to do it once.

Cheers,

Alex
Quote Reply
Re: Changes to Search Routines In reply to
I would like the category names as tags associated with each link. I think it's a necessary feature, and it might actually simpify some things down the road.

Right now a link has the properties of the database fields and a few others... One that should be attached 'centrally' is the "Category_Name" -- linked and unlinked.

Right now a "link" doesn't have it's category name attached to it (it has an ID, but that can't be processed as a 'tag' to get the name). When the link is yanked from the database, things like "DaysOld" and "Category_Name" and "Category_Name_clean" should be attached to the 'link' so they are available in the template.

It would also be nice to be able to use different links.html files for different pages, but that may come with dynamic pages. It actually shouldn't be too hard, just doing a similar thing for "links.html" as you did for build_sort_order.
Quote Reply
Re: Changes to Search Routines In reply to
rajani,

That is not what I said, or implied.

The relative catalog, numerical indexing is the _proper_ way to relate a database. What I'm saying/asking is when the link is processed, the attributes of the link should be calculated by perl, so they are available to the Links Template Parser. The Links Database Storage Object can be much smaller than the Links Database Working Object. Because PERL can quickly calcualte and update these extra fields when a link is accessed -- no need to store that data in the database.

I feel the database should use a 'links count' rather than a 'primary' 'alternate' type system, but that's a matter of philosophy, not functionality.

As for the code, it's _NOT_ a nightmare, and by adding in a lot of the suggestions and rewriting the engine from scratch, many of the "modifications" to links output are now made in the Links.pm file, rather than in multiple edits to the source code.

My fear is that Alex will get frustrated and try to take some shortcuts, rather than keep the code all properly oop, modular, and cofiguration-addressable.



Quote Reply
Re: Changes to Search Routines In reply to
Hello Alex!

If you do remember my long debate on Alternate Categories ./. Multiple Categories where I did mention this problem.

I do realise more and more that the very nature of programming you have done is extremely good but need a lot of modifications. If I sit down or anyone else, it would be a nightmare, but if you do so, it would be in the interest of everyone, not only the users but also you as a seller.

I had clearly mentioned that a relative MySQL_ID is a system that you have used and this will always give problem as one cannot work with it. If it was CatID_Link_ID which is an absolute system within a database that would help all the link users for all kinds of further processing and woking and better handling of each link by the nature of their IDs.

My suggestion was CatID.LinkID in a seperate column. It is this CatID associated with each link that may help a lot.
www.gossamer-threads.com/scripts/forum/resources/Forum9/HTML/000081.html

The biggest problem in this situations is to urgently work on this areas before people start their projects with Links SQL. This is an area that is directly related with IDs and should be at the top.

People did not realise all what I was talking about. More the users join, the problems will surface again and again.




[This message has been edited by rajani (edited October 04, 1999).]
Quote Reply
Re: Changes to Search Routines In reply to
Hello!
Quote:
The relative catalog, numerical indexing is the _proper_ way to relate adatabase.

This is correct but what i wonder is whats wrong if this number is a decimal instead of a number for e.g. Instead of 12345 of the Links ID it can be 387.12345 where 387 is the Category_ID.

In this system one can have the primary key always under control. If a link 387.12324 is deleted than it will be within the area of numbers 387.123XX and still the over numbering system remains the same. also every additions can still occur in terms of an increment of fractions of 0.00001 and not 0!

In this way the value of the category is then attached to their Links_IDs already. This could possibly make the life easy.

Even to calculate the statistics one could refer the number between x ~ y and the difference would immediately give statistics. Currently Links SQL goes to sleep when I want to build all webpages.

You can simply copy your categories again and again make it about 10,000 categories insert ten links and check it out my how deep are my frustrations of purchasing Links SQL.

It not only shall generate Kilometer long Category listings but will also sing wonderful lyrics while calculating statistics.

The most unfortunate part of the story is that Alex has no solution and nor the interest to offer any support at all.


www.gossamer-threads.com/scripts/forum/resources/Forum9/HTML/000137.html


I have not been able to even import one Link from Access database. Pathetic.

------------------
rajani











Quote Reply
Re: Changes to Search Routines In reply to
The reason you can't (or shouldn't) use decimals, is you _must_ use them as "strings" and ensure that all arythmetic is done on "strings" not as decimals.

The reason is rounding, that to store a decimal you use a type REAL, and the internal computer representation of that is system (hardware and OS) dependent.

Quote:

I have not been able to even import one Link from Access database. Pathetic.

Yes, you are.

I don't remember anywhere about LinkSQL working with "Access" -- only that it was PURE PERL CODE, and used no system-dependent routines. I've managed to import my data every way I've needed to. Some has taken more work that I'd like to do all the time, so I'll write an import/convert routine.

MySQL has a variety of import routines already built in, and using them is not very difficult. If you can export a database in any common format, MySQL can read it in.

Once it's in the SQL database, the data can be exported in any way you'd want, and that export is now SQL/MySQL compatible, and can be altered, imported, or modified easily.

SQL databases have formerly (as of even a year ago) been the area of EXPERIENCED and DEDICATED computer nerds. Now anyone can set up and use an SQL database, but not everyone is EQUIPED or ABLE to maintain one.

I no longer have an idea of what you are doing, or what your site is trying to do, but from your attitude and requests, I think you are somewhat optimistic to expect to get it done with a $400 beta/release 1.0 program. Not to short change Alex, but if you want to play in the "big leagues" you need to ante up. Otherwise, zip-up and just DO-IT..

There are dozens of people who will take your Access database and import it into SQL for you. There are hundreds of SQL consultants, programmers and database technicians who are available to solve your problems if you are not capable on your own.

The reason I post here, rather than just mod the program myself, is that I think some of my suggestions will make a better program that others can benefit by, and I benefit by the feedback and Alex's continued efforts as well.

In general, this SQL area has been a B&M area, without much constructive interaction. Unfortunately the discussions and efforts of the other forums don't apply to this version, as the SQL engine changes the fundamental 'theory' of the program.


Quote Reply
Re: Changes to Search Routines In reply to
Hello Mr. Pataki!

The reason why I have put everything on hold is because Links SQL needs to be developed much more and the claim of "Large directory" is only a flowry one, I realised.

Alex wrote me in an email, import from Access database can be done with a click. The problem is in the time routine. When I export from Access it gives date format + time XX:XX:XX and the import.pl is not yet intellegent enough to understand it. A script must provide such things at least.

An argument of "Just $400.00 for the script and so it cannot give very much or one cannot ask more!" is non-sense. For a programmer it is no big work to modify a little bit of routine where one clicks in the admin to import.pl what is the style of date format, if it also contains the time information. If it does then it can filter it. Or atleast someone should say how to. The routines are already there but not fully used. To be able to use them I have to zip my pants and learn perl, ... is what one could say. WinNT costed me half and Win 98 even less. It ofcourse depends on the users, but if one joins less number of users it costs more.

Quote:
I think you are somewhat optimistic to expect to get it done with a $400 beta/release 1.0 program.
Such an approach of Alex I can only severly critize using polite words publicly.

The very idea of a business offer "All future upgrades are for free" is also a meaning that Links SQL shall develop into a robust program meant to be for large directories. With me there are only hurdles and worst, it seems I am not in the favored group comparing to what and how Alex reacts to your wishlist. My requests are also not custom requests, but no concrete support. If a product costs $20 if I can use it good, its worth ten times. But Links SQL is a nightmare to use for large directores like mine and if it does not progress than its worth nothing. For me it creates Kilometer long listings. It calculates stats for hours. It cannot import the Flat file ASCII txt database (exported from Access) in to MySQL databse because it has the date format of |date XX:XX:XX|


------------------
rajani













[This message has been edited by rajani (edited October 05, 1999).]
Quote Reply
Re: Changes to Search Routines In reply to
The date can be imported into MySQL in MMDDYY format. You need to remove the ':' or change them to a '-'

In the import routine (if it's YY:MM D) then change the last subroutine to:

Code:
sub convert_date {
# ----------------------------------------------
my $in = shift;
my ($year, $mon, $day) = split /:/, $in;
# my %months = qw!Jan 01 Feb 02 Mar 03 Apr 04 May 05 Jun 06 Jul 07 Aug 08 Sep 09 Oct 10 Nov 11 Dec 12!;
# ($day < 10) and ($day = "0" . int $day);
return "$year-$months{$mon}-$day";
}

IF the access data is in any other format, move the $year, $mon and $day variables around to match the input pattern.

This is untested, but should work.

Quote Reply
Re: Changes to Search Routines In reply to
Hello!

You did not understand. i will then posts the next and you will see.

Thanks for your support.

------------------
rajani