Forum OpenACS Development: ACS Rels (light)

Collapse
1: ACS Rels (light)
Posted by Malte Sussdorff on 07/14/05 11:53 AM
We are facing the situation again where we want to have a multi relationship mapping between objects, but where acs-rels is overkill as each relationship is an object.

In https://openacs.org/forums/message-view?message_id=238631 it was said that we should use our own mapping table, as this was inside one application.

But now we are facing the fact that we have one file (a PDF generated out of data in our invoice table (CR)) which should be stored in multiple folders (with the client, with the project and in the accounting folder) but where the parent_id is the cr_item_id of the invoice (as the file was derived from there).

Should we use acs-rels? Should we create a custom mapping table (again)? Or should we create acs-rels-light?

My first intention was to say "I don't care about overkill" due to the fact that postgres does perform well with a large number of entries in a table. But on the other hand, we do not have to tickle the devil. Judging from past experience I'm strictly against yet another custom table with yet another set of procedures that does exactly the same stuff as acs-rels, except create an object for the relationship. Which leaves me with acs-rels-light.

As acs-rels-light would not be a core package and file-storage (where we would have to change the folder-chunk view) isn't either, this does not require a TIP, but hopefully some people can say "yeah, good idea" or "no, use acs-rels and don't worry".

We are expecting around 2 million relationships per year because of these relationships, to give a more detailed figure.

Collapse
2: Re: ACS Rels (light) (response to 1)
Posted by Jose Pablo Escobedo Del Cid on 07/14/05 12:45 PM
I think that's a good idea.

Indeed, for the package I'm doing now, I created a table named 'packagename_components_map', which maps the components that are not acs objects in the package, so the acs-rels-light table would be useful to me.

Collapse
3: Re: ACS Rels (light) (response to 1)
Posted by Dave Bauer on 07/14/05 03:03 PM
Malte,

Is you acs_rels_light (please pick a better name!) for mapping objects to what?

I don't see how we can have a generic object -> non-object mapping.

Are you using something like "on_what_table" design like the old ACS 3 stuff?

Do you think it would be useful to have a way to make a CR item "appear" in multiple folders that is independent of file-storage? Right now content_symlink (object based, so not really what you asked for) almost serves the purpose of this.

One issue is that you still need to manage permissions on the "copy" and you might need to manage comments or something on a per folder basis, so you end up needed to convert to objects.

How many objects will you generate per year around these 2 million relationships? (to put it in persepctive)

Collapse
4: Re: ACS Rels (light) (response to 1)
Posted by Malte Sussdorff on 07/14/05 06:06 PM
nob-rels (you asked for a better name 😊), called "no object relationship" will do *exactly* the same as acs-rels, but not create an acs object. Therefore it will link any object to any other object.

You have a valid point with regards to permissions and though we do not need it (folder permission is enough) it might be better to use acs-rels or content-symlinks if we want to make a general solution. Though, wouldn't folder permission be enough in general (after all you just create a symlink in that folder so the users that have access to the folder can see the file). One benefits of using content-symlinks comes from the fact that we would not have to modify the folder-chunck queries (at least in theory) as content-symlinks are cr-items.

Nevertheless I think nob-rels is a good idea e.g. in the assessment example or application-(data-)links.

We expect around 1,5 million other objects per year, partialy due to the application-(data-)links.

Collapse
6: Re: Re: ACS Rels (light) (response to 4)
Posted by Jose Pablo Escobedo Del Cid on 09/02/05 06:20 PM
Hi Malte,

I'm going to do some mappings in the applicaion I'm working on now and I would like to know if you implemented the nob-rels relationship table, and if you did, where can I read how to use it or see some examples.

Thanks.

Regards,

jopez

Collapse
5: Re: ACS Rels (light) (response to 1)
Posted by Dave Bauer on 07/14/05 06:21 PM
Ok. So its just a generic mapping table for object to object, in the case of file storage, cr_item to cr_folder.

So just the relationship is not an object. I think this is a good idea in theory, but just wonder if you should not be using file-storage if you will have 2 millions links :) Since the non file storage links will greatly overwhelm the real file storage files.

Collapse
7: Re: ACS Rels (light) (response to 1)
Posted by Malte Sussdorff on 09/02/05 08:27 PM
No, we actually used symlinks, so no nob-rels at the moment. But feel free to create them :).
Collapse
8: Re: ACS Rels (light) (response to 1)
Posted by Stan Kaufman on 09/07/05 12:57 AM
Do symlinks actually work now with file-storage? I'm trying to work out how to "share" a file between two folders (in different file-storage instances in different subsites, actually) but I'm thinking that this isn't really implemented.

Say you have a file (id=$my_file_id) in a folder (id=$first_folder_id) and you want it to show up in a second folder (id=$second_folder_id):

content::symlink::new -target_id $my_file_id -parent_id $second_folder_id

will put something called a "symlink to $my_file" in that $second_folder , but the links for that "symlink" are all broken. It's impossible to download, set the "properties" etc of that "symlinked" file.

So what else does it take to make in a second folder a functional symlink to a file in an original folder?

And what about making symlinks to folders and not just items in folders? This appears to be completely unsupported at this point, eh?