Skip to main content
added 24 characters in body
Source Link
liori
  • 725
  • 5
  • 16

I have a set of objects, for which users manually applied tags, whatever they invented. I'd like to implement a task engine, where each task might be applied to objects from a tag. For convenience, I'd like to have an additional virtual tag "All objects" to have a task be applied to all objects regardless of tags.

A single task might require two (or more) sets of objects, e.g. "show"notify me about changes in all documents from tag X that were published on website tagged Y".

I see three ways of implementing this requirement:

  1. Have a separate user interface and business code paths for the "All" case. This could be feasible for simple cases, but in my case it leads to having four cases for the example above, and potentially even worse in other cases.

  2. Have a user interface that treats the "All" case like a normal tag (except maybe for making it impossible to remove items from the tag), and have business code add the tag automatically every time I list tags in the app, or have special cases for the "All" tag every time I handle a tag.

  3. Have a user interface and business code handle the "All" case like a normal tag, and implement the virtual "All" tag on the database level. That would mean using database views that would add the "All" tag to the table of tags, and another view that would add the "All" tag to the m2m relationship listing which objects have which tags.

The third solution looks the most sane to me, but I don't have that much experience with programming on the database level. I can see the pros and cons of the first two solutions. What are the issues I might encounter if I chose to implement the third solution?

I have a set of objects, for which users manually applied tags, whatever they invented. I'd like to implement a task engine, where each task might be applied to objects from a tag. For convenience, I'd like to have an additional virtual tag "All objects" to have a task be applied to all objects regardless of tags.

A single task might require two (or more) sets of objects, e.g. "show all documents from tag X that were published on website tagged Y".

I see three ways of implementing this requirement:

  1. Have a separate user interface and business code paths for the "All" case. This could be feasible for simple cases, but in my case it leads to having four cases for the example above, and potentially even worse in other cases.

  2. Have a user interface that treats the "All" case like a normal tag (except maybe for making it impossible to remove items from the tag), and have business code add the tag automatically every time I list tags in the app, or have special cases for the "All" tag every time I handle a tag.

  3. Have a user interface and business code handle the "All" case like a normal tag, and implement the virtual "All" tag on the database level. That would mean using database views that would add the "All" tag to the table of tags, and another view that would add the "All" tag to the m2m relationship listing which objects have which tags.

The third solution looks the most sane to me, but I don't have that much experience with programming on the database level. I can see the pros and cons of the first two solutions. What are the issues I might encounter if I chose to implement the third solution?

I have a set of objects, for which users manually applied tags, whatever they invented. I'd like to implement a task engine, where each task might be applied to objects from a tag. For convenience, I'd like to have an additional virtual tag "All objects" to have a task be applied to all objects regardless of tags.

A single task might require two (or more) sets of objects, e.g. "notify me about changes in all documents from tag X that were published on website tagged Y".

I see three ways of implementing this requirement:

  1. Have a separate user interface and business code paths for the "All" case. This could be feasible for simple cases, but in my case it leads to having four cases for the example above, and potentially even worse in other cases.

  2. Have a user interface that treats the "All" case like a normal tag (except maybe for making it impossible to remove items from the tag), and have business code add the tag automatically every time I list tags in the app, or have special cases for the "All" tag every time I handle a tag.

  3. Have a user interface and business code handle the "All" case like a normal tag, and implement the virtual "All" tag on the database level. That would mean using database views that would add the "All" tag to the table of tags, and another view that would add the "All" tag to the m2m relationship listing which objects have which tags.

The third solution looks the most sane to me, but I don't have that much experience with programming on the database level. I can see the pros and cons of the first two solutions. What are the issues I might encounter if I chose to implement the third solution?

Source Link
liori
  • 725
  • 5
  • 16

Implement a virtual tag on the database level

I have a set of objects, for which users manually applied tags, whatever they invented. I'd like to implement a task engine, where each task might be applied to objects from a tag. For convenience, I'd like to have an additional virtual tag "All objects" to have a task be applied to all objects regardless of tags.

A single task might require two (or more) sets of objects, e.g. "show all documents from tag X that were published on website tagged Y".

I see three ways of implementing this requirement:

  1. Have a separate user interface and business code paths for the "All" case. This could be feasible for simple cases, but in my case it leads to having four cases for the example above, and potentially even worse in other cases.

  2. Have a user interface that treats the "All" case like a normal tag (except maybe for making it impossible to remove items from the tag), and have business code add the tag automatically every time I list tags in the app, or have special cases for the "All" tag every time I handle a tag.

  3. Have a user interface and business code handle the "All" case like a normal tag, and implement the virtual "All" tag on the database level. That would mean using database views that would add the "All" tag to the table of tags, and another view that would add the "All" tag to the m2m relationship listing which objects have which tags.

The third solution looks the most sane to me, but I don't have that much experience with programming on the database level. I can see the pros and cons of the first two solutions. What are the issues I might encounter if I chose to implement the third solution?