Still looks good for a Wednesday beta release. I'm trying to shoehorn it into an Install module, and then have to make sure it works from a plug-in install.

If you have purchased this mod, or the image gallery mod, and want to beta this, email me. This is a real beta. It won't destroy your system, but it's almost guaranteed not to work on first install :) So I don't want to encourage anyone to install it who doesn't _ask_ first :)

Here is the Attach_Links table, and what it will look like. I tried to cover all the important attributes an attachment could have, as well as a few that add some extra features if you use them right.

====

Slot: will allow minor page-formatting.
File_Name: the disk-storage name
Download_Name: The download name (not yet implemented)
File_MimeType: To allow browsers/servers to deal with it
Type: Human/searchable type -- GIF, PDF, SHTML, etc
Height/Width: only if "isGraphic"
Pages: used for non-graphics, ie: PDF, Text
Resolution: Can be used to set the resolution - 72, 150, 300, etc
Topics: An admin field, for categorizing/searching behind the scenes
Content_Type: an admin field, or enum field, for "Story, Photo, Review", etc. Customizable.


If you can think of any other attributes that apply to a wide range of attachments, I can work them in, but they need to be really general. You can customize this any way you want, just like the Links record, but I'm trying to make a pretty complete default install.

Technically, LinkID, Username, could be pulled out, with ID, into a Cat_Links type table, but performance would unnecessarily suffer. For a very, very small byte penalty this creates an easy linking to Username and Link. NOTE: This is something that _is_ done in the Image Gallery mod, since the basic unit of the Image Gallery is an "Element" (or attachment) and not a "Link". An attachment/Element can be a member of several groups, "links" or series.





PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Shouldn't Username be substituted with UserID as the foreign key from the Users table? Also, what if people change their USERNAME, eh? UserID is constant and unique...(which means that the FIELD TYPE would have to be switched to INT).

In terms of improving searches of records in this table, you should set up secondary indexes of at least "indexing" the LINKID and ID fields, if not also the USERID field as well...to improve data access performance.

Regards,

Eliot Lee

Eliot,

Are we using the same Links???

Username _is_ the primary key to the Users table!

You've made some truly non-standard mods there, m'boy :)

Robert


PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Ah...

Also need to add a "pending" flag

isPending => { pos => 30, type => 'ENUM', values => ['Yes', 'No'], not_null => 1, default => 'No' },


(or maybe hasPending to the "Links" table?)

In order to make admin notification of new attachments easier.

I'm _not_ using the "modify" system, since uploading attachments doesn't modify the link, or other/existing attachments.

If I put the "hasPending" flag in the Links table, along with "hasAttachments", then links that are pending webmaster approval can be easily selected, and a graphic, or "flag" can shown that this link has been updated, ... (not incredibly useful, but has some purpose).

QUESTION: Should "new attachments" flag a "Link" as new? or, should the Link have another flag field "NewAttachments" ??

I guess it could do both, but each "feature" such as this that is added, tends to bloat the code, the processing time, and slow things down.

Flagging the Link itself as new, only requires a small code segment to select the distinct ID's for all new attachments (since the cut off date) and set the Links.isNew flag to "Yes" where Link.ID is IN that list. Of course this gets toggled on repair tables or 'build' (but will be reset again on a build-hook (I hope!). This will allow/cause a Link to be flagged as "new" if it has a new attachment.

Using the flag field in the Links table, means you can set attachments to age separately, adds overhead to each link record, and will not show the links as "new" on the "What's New" list.

Either way would allow you to create a "New Attachments" list, similar to the Whats New Links list.

Any of this make sense?? <G> You can tell this is getting ready to go out, since this is splitting hairs to some degree... but still needs to be considered.


PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Seems I'm going to miss the wednesday release, but if I can't get this all stuffed into a package for release on thursday, I'll set up a demo, so you can at least see what it does, and maybe point out bugs to fix while I'm packaging it.

I might also drop the designation of this release from 'beta' to 'alpha' if I can't get the table installer to work as needed. That will mean you'll run the plugin setup, but you'll have to issue a cut/paste into the SQL monitor to set up the tables (or vice versa). The guts of the program is working at beta level, I'm just having a bit of a time packaging it for distribution.



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Ok....

As always happens, in packaging this for release, I've solved a few of the more perplexing issues, but that's forced a re-do of some internal logic and the templates. Good news is that it looks like rather than releasing a beta1, I'll be releasing close to a final beta, with what I hope will only be the inevitable bug fixes.

I figure if things go well, I could have an early version this weekend, but I should have a "solid" version that you shouldn't be afraid to install Tues or Wed!! For real! Finally! This monster is done!

Image::Size version 2.93 now also can identify PSD (Photoshop) and SWF (Shockwave/flash) types.

The graphics processing is internal, and "text/ascii" is figured by the upload status. Types like PDF can be added, but will be treated as generic binary types by the program (at least for now). The program can also be set to accept _only_ binary files of a known graphic type, and will reject any text/ascii or unknown files. (I guess I'll have to add a "text only" option as well now...)

I've added a few extra fields to the Attach_Elements table, but eliminated the intermediate tables, and all uploads are registered in the database the moment they are saved to the server. No free-floating files (those would be considered "orphans" and subject to deletion). "State" is actually saved in the attachment record itself, as a set of attributes to the element itself. "isPending", "isValidated", "hasErrors", "isGraphic", etc. It imposes a few bytes per record overhead, but eliminates a whole host of potential redundancy errors, and data copying between tables and directories, as well as the need to keep "state" information in cookies, sessions files, or anywhere, actually. Each element knows it's own "state".

Rather than trying to track errors, and save "state", the errors are written to the "hasErrors" field of the database record. If the errors are of the type that prevent the file from being properly processed, then the file is unlinked, but the database record remains, flagged as "hasErrors".

When the attachments are uploaded, a "Select * from Attach_Elements Where LinkID = ID" is done. This 'attaches' the attachments to the Link record for display. Any record that "hasErrors" will be presented as a "failed" upload, and this will be persistant for as long as the record is pending validation ie: all the attachments are marked as "isValidated = 'Yes'". When the last attachment for that link is marked "isValidated = Yes" then all attachments that are flagged as "hasErrors" are deleted. This allows a user to keep trying to upload an attachment, and be reminded that it failed, even session to session, days later, without cookies, sessions or other funky methods.

This may be confusing on read, but it solves a whole host of problems. It allows both single and multiple file uploads, and allows this to occur in the stateless world of the web. It cuts out all sorts of intermediate tables or state files.

I'm assuming that "most" people will want to run this with the Logo mod, but not the graphic mod (since that is essentially what the attachments file is), so the templates will be set up to allow both Logo and Attachment editing. You can always remove those links if you don't want them. It's easier to remove them, than figure out how to add them, and to add the UploadGraphic tags, you'd just copy the Logo tags... so it works well :)

This also brings up the point that by using the "Logo" mod you can assign one of the thumbnails to the link, for display, or, if you are using the mod for uploading images primarily, then with a snippet of random code, you can have the template pick a thumbnail from the attached links to display with each link on the search and catalog pages.... The possiblities are endless :)

This is actually the 9th distinct version of this program I've worked on since about January. Every other attempt started to fall apart in some way as it was worked on, and I didn't want to release something that would change drastically between each release. This version is much more durable. It has taken major internal changes without falling apart, and has adapted to the database changes, logic changes, template changes, and all the other tweaks with only minor fixes, rather than sweeping code changes. That's a very, very good sign :)



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum