Gossamer Forum
Home : Products : Gossamer Links : Pre Sales :

Some things to solve ...

Quote Reply
Some things to solve ...
Hi all,

im have to work out the following things and maybe someone has a solution for me:

1. I need more then one detailed.html; so i want to give an additional field for every link; e.g. with values '',1,2,3,4
and when building it goes: Take value from field, and build with detail+"value".html, so it could be detauiled.html, detailed1.html and so on.

2. i have a "unique" field named "dirname" for every link; how could i set links not to build /detailed/ID.html but
detailed/dirname/index.html

3. How can i easy stop the !building! of new and popular; i dont need them and want to mimimize serveraction.

4. How many people could use the add/modify-forms at the same moment?

5. What happens if i set some "editors" and they work on links at the same moment than i, the admin, do that.
What is when they work at the same time?

6. Has someone expirenced the "like" from SQL; as i read its very easy to get a value from a textfield with:
select from table where field like "something"

7. In category-building, i need the name of the category; so i want a SQL-Select:
Search for Links with "category-name" in keyword-field (i do this from another database with theme-content)

Small things i hope :-( and the night is short :-)


Robert





Quote Reply
Re: Some things to solve ... In reply to
1) One easy solution is using the info.cgi Mod written for Links 2.0, which can be easily modified to work with Links SQL...I modded widgetz's detail.cgi to parse data from three different tables in my Links SQL database. Alternatively, all you have to do is copy the variables for Detailed pages in the Links.pm file and then make copies of the sub build_detailed_view to build the extra detailed pages. You will have to change some of the variables in these new subs to include field names before the extension variable.

2) See the following line:

Code:

$filename = $LINKS{build_detail_path} . "/" . $link->{'ID'} . $LINKS{build_extension};


in the sub build_detailed_view in the nph-build.cgi file?

Change it to the following:

Code:

$filename = $link->{'dirname'} . "/" . $link->{'ID'} . $LINKS{build_extension};


4) It really depends on how much traffic your site receives, CPU rates, Memory, etc. There is really no absolute number.

5) You could experience some delays in processing requests from the server and if you are editing the same category at the same time, there is a risk of duplicating ID numbers for Links.

6) I don't understand your "like" request.

7) Category searches have been discussed many times in the Links SQL Discussion Forum and I believe that widgetz did upgrade his Links 2.0 Category Search to Links SQL and the codes are located in the forum I referred to.

Hope this helps.

Regards,

Eliot

Quote Reply
Re: Some things to solve ... In reply to
Elliot,

The duplicate ID number problem is unique to Links 2.0, and flat files. It's somewhat impossible with Links SQL, since the ID field is an auto-increment field, and as such is defined as _unique_.

Additions grab the next available ID number (that is what the ? is for), and insertions should also use a ? for the ID field, or risk getting an error message "Duplicate Key" or "Duplicate Field Value" or similar.

Using an auto-increment field is probably the best way to guarantee each record in a database has at least one UNIQUE identifier, and it satisfies the rules for normalizing tables.

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Some things to solve ... In reply to
Thanks for the pointers, pugdog. Although I believe I read a Thread awhile back in the Links SQL Discussion forum that discussed duplicate IDs numbers. May be I was hallucinating. Wink

Regards,

Eliot

Quote Reply
Re: Some things to solve ... In reply to
No, you weren't, but I think there was a different solution/reason for what was going on.

I'll see if I can find that thread (or if you can). But if you look at the table definition for any of the tables manged through DBSQL.pm and the "add" routine, the ID field is automatically generated, and unique. I had a problem early on trying to use DBSQL.pm with tables where I was using a different key field. I gave up and added the ID field even if I wasn't using it. Alex considered (and may have) made changes to allow use of the routines with the "?" auto-increment field as the first field, but I never really went back. I just changed my own logic and thinking to use ID #'s as the key field.

I might be subtly confusing things, I'll have to check -- (see if I can insert another record with the same ID in a table) _BUT_ in links, the ID (auto-increment) field is declared as "PRIMARY". Primary is a "UNIQUE" key, and thus, whether or not "AUTO_INCREMENT" allows duplicate values, the "PRIMARY" attribute to that field would not.

An AUTO_INCREMENT field must be indexed, but I can't find documented anywhere if it has to be "UNIQUE."

In Links, it _IS_ UNIQUE by virtue of being declared "PRIMARY".



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Some things to solve ... In reply to
Thatīs the way i love this little place in net :-)
Just a look before beginning my nightly work and finding some good answers to my quest.
So let the games begin ...
Thank you both.
Robert

Quote Reply
Re: Some things to solve ... In reply to
You're welcome. And have fun!

Regards,

Eliot Lee