storage table

I wonder if this will result in a large number of queries that are related for a module, and if so, whether we should introduce a realm on the storage table? The advantage would be that we could load all the storage-variables of one realm together. The reasoning is, if I need one of the variables I set in my module, I'm likely to need most or all of them, at which point it seems like it would be more efficient to load them all. Perhaps the solution, in fact, is to add a realm column to the variables table? Then we could differentiate between different blocks of related data and load it into conf as needed.

grrrr! Can't edit follow-ups in project module =(

please, do not bother people with more database stuff then is needed.
I love the variable_get /set for its ease of use. Taking this away from developers for some possible" performance increase is a big No Go IMO.

I like the addition of storage_set and get, but not teh extra parameter in variable set.
I amlso fail too the what this is really about. It simply splits variables into two tables. Nothnig more, nothing less. thatIMO noly adds clutter. And sorage_get should have a default value, like variable_get.

I would say -1 for this. And a +1 for making variable_get smarter.

what is the goal here?

i do agree wholeheartedly that we should somehow associate variables with modules. the variables tablegets crufty after a while and that can be dangerous if the crufty variables are large in size. it can take a long time to unserialize large strings. this is a performance issue.

Code like this: db_query("DELETE FROM {$table} WHERE name = '%s'", $name); won't work because PHP will treat the "{}" in {$table} as variable delimiters and will remove them before passing to the function.