CODERS PLEASE DISCUSS!!! Pre-Datastore modifications with XML-files (UPDATE 28-7)

[merk]

But since templates can already be cached via a hook, why does this system need to deal with that?

Similar modifications could be made to other datastore types, though they would probably have to drop the active checking, although, if you set a product as inactive, it could write to the other datastore methods at that point.

The end user doesnt need a script to add rows to the new table, the product xml file should deal with that bit automatically.

[Andreas]

Phrasegroups for Example currently can't be done with Hooks (at least not for Guests).

I don't really get how you would go about implementing this Idea with other Datastore Classes.
Maybe some example Code?

[merk]

Looking at the other classes, it shouldnt make any difference.

The other datastore types (file based or memcached) appear to fetch a datastore item if it doesnt exist in their specific storage mode and add it. Meaning it only needs to be uncached for one page load, then its added.

Im not sure how it deals with updated datastore items. I guess the build_datastore() functions deal with that too.

Didnt think of phrasegroups, but it shouldnt be hard to add phrasegroups either - Take a look at the deletion log table and how it is joined into multiple different types of items that could be deleted (posts, threads, pms)

Add a new column to the new table of type

[sql]
AND _NEWTABLE_.type = 'datastore' / 'phrasegroup'
[/sql]

[Andreas]

Originally Posted by merk

The other datastore types (file based or memcached) appear to fetch a datastore item if it doesnt exist in their specific storage mode and add it. Meaning it only needs to be uncached for one page load, then its added.

Right. But how would the Classes determine if an item has to be cached if it's not in $specialtemplates?
That's the important question

[merk]

Originally Posted by KirbyDE

Right. But how would the Classes determine if an item has to be cached if it's not in $specialtemplates?
That's the important question

Hope it doesnt come across as arrogant - but it doesnt matter. (From what I see from something like the Memcached class, all datastore items that have ever been "queried" are added to the Memcached cache, but a single query happens if it doesnt exist, but only the first time).

From what I see, the $specialtemplates variable is only useful if you want to save queries to the database while using the traditional datastore method.

If the item doesnt exist in the memcached/filestore storage, it will be queried. But only once. After it has been queried, it will be added to the relevant storage.

The biggest issue I see is that what happens when the datastore item is updated in the database. I do not see how it will update the item in the other storage methods - I suspect that it gets updated when you call the build_* functions. I havent looked at that area because I use the database method

[Andreas]

Seems like you don't understand me, or I don't understand you

Let's say a Hack needs attachmentcache which isn't in $specialtemplates for the Script.
What should the Plugin do in order to get this?

[merk]

Originally Posted by KirbyDE

Seems like you don't understand me, or I don't understand you

Let's say a Hack needs attachmentcache which isn't in $specialtemplates for the Script.
What should the Plugin do in order to get this?

Maybe just a crossed wire

1) The plugin that accesses a hook should do the standard thing it does to access the datastore item. (IIRC, $vbulletin->name) - however, it may need to be unserialized. I dont see an issue with unserializing in global_start.

2) The product should add a row into the NEWTABLE table with relevant details of the datastore item. Name, Product ID, Scripts that the datastore item should be loaded on (THIS_SCRIPT names) and any other details that are needed - havent fully thought of them.

At this point, the datastore class for DB type will query the datastore table joining the new table into it looking for conditions that match to load extra items (or if it exists in $specialtemplates). See query I posted above.

For the other datastore types, (because there are no queries involved for other types) it should be as simple as querying the datastore table once (an extra query for one page load) to load the datastore item into the other types' storage method.

There is an issue with this in that if the datastore item updates in the datastore, the product will have to deal with it gracefully and update the datastore properly, calling the datastore methods that do the magic they do.

[Andreas]

Originally Posted by merk

1) The plugin that accesses a hook should do the standard thing it does to access the datastore item. (IIRC, $vbulletin->name) - however, it may need to be unserialized. I dont see an issue with unserializing in global_start.

Well, the Item won't be available as $vbulletin->name if it wasn't in $specialtemplates before calling global.php.
And as Plugins are being loaded out of the Datastore it can't be added through Hooks. That's the whole point of this Thread:
We've got a "Chicken and Egg" Problem here
As I already said, your suggestion works fin - when the default Datastore Class (Database) is being used.
But what's your solution when using other Datastore Classes?

For the other datastore types, (because there are no queries involved for other types) it should be as simple as querying the datastore table once (an extra query for one page load) to load the datastore item into the other types' storage method.

Ah, now there we go.
Sure, that would be possible - with the dabwack of having an additional Query for every Pageload.
And that's what the discusssion here is all about: Which approach adds the smallest Overhead possible?

There is an issue with this in that if the datastore item updates in the datastore, the product will have to deal with it gracefully and update the datastore properly, calling the datastore methods that do the magic they do.

The Datastore Classes will take care of Updates, that's not a Problem.

[merk]

Originally Posted by KirbyDE

Ah, now there we go.
Sure, that would be possible - with the dabwack of having an additional Query for every Pageload.
And that's what the discusssion here is all about: Which approach adds the smallest Overhead possible?


The Datastore Classes will take care of Updates, that's not a Problem.

<!-- edit: this bit can be ignored, next para solves the solution in my opinion: As far as i can see there will only ever need to be ONE query if the item doesnt exist in the other datastore types' storage. Not fully grasping what happens with them, i suspect thats how it works. (At least thats how it appears to look).

After the single query on the first pageload it is requested on has passed, there will be no more queries. -->

There also wont be any queries if the product builds its datastore item using the class, because the class will deal with the build and will put it into the proper storage.

And as long as the product manages datastore changes properly - it isnt an issue.

[Andreas]

Originally Posted by merk

As far as i can see there will only ever need to be ONE query if the item doesnt exist in the other datastore types' storage. Not fully grasping what happens with them, i suspect thats how it works. (At least thats how it appears to look).

How does the Datastore Class (on subsequent Pageloads) know that there are no Entries that need to be cached, and thus does not execute the Query?
How does it know which entries need to be made available as $vbulletin->name?