[WebDNA] Recall with different scopes ...
2015
It keeps the original formatting.
interpreted = N
texte = >> Why would it matter if the same volume of data were stored in >> a single db or in separate dbs? > > Just want to take this opportunity to make a parenthesis: > several small databases are usually faster than a large one. Good point. However, in my case my default reserved.db will always be small. I can see myself using it for a few dozen code snippets but probably never more than that. So realistically, at least for me, the default reserved.db will be extremely small and therefore insignificant in terms of RAM use. > One single modification in a database, in case "Automatically > commit databases to disk after modification" is checked, will > have to write few hundred KB or few MB instead of tens or > hundreds of MB to disk. Good point. However, I never have my prefs set to "Automatically commit databases to disk after modification" because I prefer to commit when I think it is actually necessary, rather than deal with the overhead caused by committing all the time. Having said this, I think we should keep in mind that the reserved.db will seldom be written to anyways -- assuming it is used as I understand it should be used -- to store permanent variables for site-wide use. After all, how frequently do we change our permanent variables? In my case, almost never! Case in point: I already have a "siteCode" file that I use to store frequently used (permanent) variables. I include it at the top of every page of the site. It sets a bunch of values so I can use them conveniently whenever I need them. If I were to replace my siteCode system with your new store/recall system: 1- I would almost never use [store] because I seldom change the values in my siteCode file as it is. 2- I would switch from putting [include /siteCode] in every page to NOT including my siteCode file any more. 3- I would switch from using simple [thisIP] tags to using slightly longer [recall thisIP] tags. BY THE WAY ... I just had a new thought after considering how and where I use my permanent variables. I would definitely use both server-wide and site-wide permanent variables, but I can never see myself using folder-specific permanent variables. Nevertheless I think it would be great if you could implement these three new scopes for permanent variables, or at least the first two: [recall abc] [siteRecall abc] [localRecall abc] Then when I use [recall] it will use the single default reserved.db located at /WebDNA. And when I use [siteRecall] it will use the reserved.db file that's located in the document root folder (/) of the current website. And when someone else (because I will never use this one) uses [localRecall] it will use the reserved.db located in the same folder as the current template. So basically this gives us three different scopes for our new permanent variables. What do you think about this? Doing it this way would let us set specific folder paths in different site scopes like this, all on the same server: site #1 reserved.db: from to imageFolder /images site #2 reserved.db: from to imageFolder /Pix site #3 reserved.db: from to imageFolder http://someOtherServer.com/site3/images Then in each website we can reference our images like this:
And when we need to move all the images in one site to a new location, running this code ONE TIME -- from a template inside the specific site we're dealing with -- would change all our image references in the entire site to the new location: [siteStore]imageFolder=/newImgFolder[/siteStore] Chris, you asked for discussion regarding your new proposed features so I hope I'm not overdoing it here. If I am, just tell me and I'll stop. :) Adding more to this proposed system: You could (if you wanted to) implement a single [recall abc] tag that works in all three scopes mentioned above. Here's how I would implement if it I were writing the code: First I would look for a "from" value of "abc" in the reserved.db located in the same folder as the current template. When found this is the value returned. But when not found it would look in the reserved.db located in the website's document root folder. Once again if found it would return this value. But when not found it would look in the default reserved.db that's located in /WebDNA. This system would certainly simplify the number of different tags we use to recall our data! However, it would also make it impossible to get a value from a specific reserved.db ... UNLESS we use the optional "path" parameter. My thought here is that whenever we specify a "path" in our recall tag, that would be the only reserved.db used, regardless of how many other reserved.db exist in the server. In terms coding in WebDNA I like the simplicity of using a single [recall] tag to find its value. After all, this means we do not have to remember which db we stored a specific value in, because it's going to come from the reserved.db with the narrowest scope. Would a system like this force us to give up any flexibility? Or would this be a better way to do it? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
Associated Messages, from the most recent to the oldest:
|
And when we need to move all the images in one site to a new location, running this code ONE TIME -- from a template inside the specific site we're dealing with -- would change all our image references in the entire site to the new location: [siteStore]imageFolder=/newImgFolder[/siteStore] Chris, you asked for discussion regarding your new proposed features so I hope I'm not overdoing it here. If I am, just tell me and I'll stop. :) Adding more to this proposed system: You could (if you wanted to) implement a single [recall abc] tag that works in all three scopes mentioned above. Here's how I would implement if it I were writing the code: First I would look for a "from" value of "abc" in the reserved.db located in the same folder as the current template. When found this is the value returned. But when not found it would look in the reserved.db located in the website's document root folder. Once again if found it would return this value. But when not found it would look in the default reserved.db that's located in /WebDNA. This system would certainly simplify the number of different tags we use to recall our data! However, it would also make it impossible to get a value from a specific reserved.db ... UNLESS we use the optional "path" parameter. My thought here is that whenever we specify a "path" in our recall tag, that would be the only reserved.db used, regardless of how many other reserved.db exist in the server. In terms coding in WebDNA I like the simplicity of using a single [recall] tag to find its value. After all, this means we do not have to remember which db we stored a specific value in, because it's going to come from the reserved.db with the narrowest scope. Would a system like this force us to give up any flexibility? Or would this be a better way to do it? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
Kenneth Grome DOWNLOAD WEBDNA NOW!
Top Articles:
Talk ListThe WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...