Re: [WebDNA] db admin tool
This WebDNA talk-list message is from 2008
It keeps the original formatting.
numero = 101476
interpreted = N
texte = It would be nice if this was done by convention and not configuration. For example, a products.db with fields id, maker_id and descriptionwould mean that maker_id refers to maker.db and the field id. This isa rails idiom and works nicely. It would mean all thosenon-conforming legacy databases would need renaming.I think of convention as everyone driving on the right side of theroad. A lot of people go to work that way, but not race car drivers.They burn a lot of fuel to drive in a circle.On Wed, Nov 19, 2008 at 8:32 PM, Kenneth Grome
wrote:>> Because there is no mechanism for structuring key fields>> and relationships between databases, it would be a huge>> task to write something that would figure all that out>> automatically.>> The tool doesn't have to figure it out automatically, the> user can simply define these relationships the first time> it is used, and at any other time he feels like it. Then> the key fields and relationships (and other operating> parameters) can be stored in a toolprefs.db file for use> again later.>>> I actually started building a modern, ajax driven db>> admin tool that is much more powerful than the one built>> in the 90s. Essentially it does everything you need =96>> create a db, edit a db, remove fields, add fields, add>> records, remove records, edit records, search, delete db,>> backup dbs, restore dbs, etc.>> I did this many years ago too (not in ajax though) and I> think I called it Ken's DB Admin. It did everything you> mentioned here and more -- including moving fields around> into different positions so you could change the field> order dynamically any time you felt like it ... :)>> But I used cookies to store the control parameters instead> of storing them in a separate preference file, and later I> learned that cookies aren't the best way to store this> data. Somehow they created an unusual situation where a> user would have to delete them to continue using the tool.>> I never figured out why this happens but if I were to> rebuild it I would most definitely use a prefs file. But> back in the 90's I was determined to make this tool a "one> file" solution so I used cookies to avoid the need for any> additional files.>> ------------------------>> There's an important issue here that makes this kind of a> tool dangerous to use in some situations too unless you're> aware of it. I only learned this after I had finished> coding my db admin tool:>> When a db contains encrypted data you cannot edit that field> without screwing up that record or possibly trashing the> entire db. So if you use this kind of webdna tool you must> limit its editing use to only those fields that contain> non-encrypted data.>> Naturally the tool could be built to disable editing of> encrypted fields, but it cannot figure out which fields are> encrypted all by itself, so this is an important setting> the user must make in the prefs before the tool will> function properly -- just like setting the name of> the "sku" field in each db so it knows which field contains> a unique value in each record.>>> Sincerely,> Ken Grome>>>>>>> ---------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us> old archives: http://dev.webdna.us/TalkListArchive/>
Associated Messages, from the most recent to the oldest:
It would be nice if this was done by convention and not configuration. For example, a products.db with fields id, maker_id and descriptionwould mean that maker_id refers to maker.db and the field id. This isa rails idiom and works nicely. It would mean all thosenon-conforming legacy databases would need renaming.I think of convention as everyone driving on the right side of theroad. A lot of people go to work that way, but not race car drivers.They burn a lot of fuel to drive in a circle.On Wed, Nov 19, 2008 at 8:32 PM, Kenneth Grome wrote:>> Because there is no mechanism for structuring key fields>> and relationships between databases, it would be a huge>> task to write something that would figure all that out>> automatically.>> The tool doesn't have to figure it out automatically, the> user can simply define these relationships the first time> it is used, and at any other time he feels like it. Then> the key fields and relationships (and other operating> parameters) can be stored in a toolprefs.db file for use> again later.>>> I actually started building a modern, ajax driven db>> admin tool that is much more powerful than the one built>> in the 90s. Essentially it does everything you need =96>> create a db, edit a db, remove fields, add fields, add>> records, remove records, edit records, search, delete db,>> backup dbs, restore dbs, etc.>> I did this many years ago too (not in ajax though) and I> think I called it Ken's DB Admin. It did everything you> mentioned here and more -- including moving fields around> into different positions so you could change the field> order dynamically any time you felt like it ... :)>> But I used cookies to store the control parameters instead> of storing them in a separate preference file, and later I> learned that cookies aren't the best way to store this> data. Somehow they created an unusual situation where a> user would have to delete them to continue using the tool.>> I never figured out why this happens but if I were to> rebuild it I would most definitely use a prefs file. But> back in the 90's I was determined to make this tool a "one> file" solution so I used cookies to avoid the need for any> additional files.>> ------------------------>> There's an important issue here that makes this kind of a> tool dangerous to use in some situations too unless you're> aware of it. I only learned this after I had finished> coding my db admin tool:>> When a db contains encrypted data you cannot edit that field> without screwing up that record or possibly trashing the> entire db. So if you use this kind of webdna tool you must> limit its editing use to only those fields that contain> non-encrypted data.>> Naturally the tool could be built to disable editing of> encrypted fields, but it cannot figure out which fields are> encrypted all by itself, so this is an important setting> the user must make in the prefs before the tool will> function properly -- just like setting the name of> the "sku" field in each db so it knows which field contains> a unique value in each record.>>> Sincerely,> Ken Grome>>>>>>> ---------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us> old archives: http://dev.webdna.us/TalkListArchive/>
"William DeVaul"
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The 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...
Related Readings:
RE: Missing contexts on NT (1997)
Listserver problem (1997)
Search design (1997)
Re:Need help... (1997)
WebCatalog 2.1b3 - Plugin or cgi ? (1997)
Formating found categories (1997)
Formulas.db + Users.db (1997)
.tmp files (2000)
Upload Plugin (1998)
WebDNA 6.0 backwards compatible? (2004)
Nebulous slow-down problem (2000)
Can this be done? (1997)
WebCat2b12 - nesting [tags] (1997)
Resume Catalog ? (1997)
WebCat2b13 Mac plugin - [sendmail] and checkboxes (1997)
Locking up with WebCatalog... (1997)
two unique banners on one page (1997)
Secure Web Server (1999)
Online reference (1997)
Summing fields (1997)