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 description would mean that maker_id refers to maker.db and the field id. This is a rails idiom and works nicely. It would mean all those non-conforming legacy databases would need renaming. I think of convention as everyone driving on the right side of the road. 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 description would mean that maker_id refers to maker.db and the field id. This is a rails idiom and works nicely. It would mean all those non-conforming legacy databases would need renaming. I think of convention as everyone driving on the right side of the road. 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:
Strange intermittent WebDNA problems Workaround (2008)
Virtual hosting and webcatNT (1997)
Email Problem (2006)
setting username and password using a form. (2000)
Checking for pre-existing passwords (1998)
Pipes instead of tabs (1998)
Plugin or CGI or both (1997)
Separate SSL Server (1997)
Date math (1997)
StandardConversions.db (1998)
emailer (1997)
Bug? (1997)
Cold Fusion Buster (1997)
Did you hear about this? (1997)
Maybe off topic but how to charge (1997)
URL'ed value not written to DB URL'ed (2003)
[add] context causing WebStar to crash! (2000)
RequiredFields template (1997)
Who is doing sign-ups-got it (1998)
restart needed???? (1997)