[Marco van Herwaarden]

Originally Posted by merk

If the plugin system is disabled, it could set a flag in the system (somehow) to also not load the extra datastore items, though it probably wont work because vboptions is in the datastore.

I don't think that would chang a lot, since it would have to be stored somehow, it would also have to be retrieved, resulting in an extra query. (Not that an extra well designed query should always be such a big issue).

Originally Posted by merk

Not having looked at your proof of concept, I would have thought the only file modification needed would be in the datastore class to modify the query. It shouldnt be necessary on each pageload to do anything else..

To implement it, only 1 modification to the datastore class is made. Ofcourse this added code must be executed on each pageload, how you would want to retrieve the info otherwise?

The other modifications are management code (loading the table with the product XML-File, disabling the entry when the product is disabled, etc.)

Originally Posted by merk

I dont see creating another table as an issue - the more tables you have to deal with things the better! - I also dont believe that a query joined to this table would be slower than reading an XML file from the filesystem.

Creating another table is not an issue if Jelsoft is doing it, it is something to consider when a Third Party (us) is making changes to the database design.

Originally Posted by merk

Template caching can already be achieved with a hook..?

I am taking the word of others on this, not tried it myself, but this was the beauty of Alternative 1 in my eyes. We could ofcourse always create something similar to the datastore hack for this. (Could be stored in datastore, so no extra query would be needed.)