Re: [WebDNA] Use of MySQL with WebDNA
This WebDNA talk-list message is from 2010
It keeps the original formatting.
numero = 105822
interpreted = N
texte = Each time a record is added, your database is written to disk. This is = fine except if your database is large and that you get several new = entries every second. WebDNA 7.0 does not anymore write to disk for = every single [append]: There is now (WebDNA 7.0) only three ways for WebDNA to write to disk: - the Administration configuration that says "Automatically commit = databases to disk after modification" - [closedatabase db=3Dname.db] in your template causes the specified = database file (or full path) to be written and closed. This is only = needed for special cases (usually before appending to a file) where you = need to change a file perhaps cached in RAM. - [commitdatabase db=3Dname.db] in your template causes the specified = database file (or full path) to be written but not closed (so it remains = in RAM) I wonder if [spawn][commitdatabase db=3Dname.db][/spawn] could not be = associated with an [exclusivelock]: that would be a way to flush the db = once in a while without any speed loss.... we will have to test this. - chris On Sep 28, 2010, at 10:45, Toby Cox wrote: > I hadn't thought of this, but now that I think of it we also have a = problem with large, heavy traffic, heavy write DBs >=20 > On an ecommerce site we run, one particular db currently stands at = 58,000 records (just over 1Mb) and it has started to corrupt records in = the last 4-6 months. Obviously this is something that tends not to = happen with MySQL. >=20 > High traffic large databases with little writing do just fine, as do = high traffic smaller DBs with lots of writing. We have a record of all = dispatched items that gets written to just a few hundred times a day. = This stands at 167,000 records and 1.2Mb and is just fine. >=20 > Meanwhile, with CakePHP and MySQL we have large DBs (250,000+) that = are written to 1,000+ times per day with no corruption. >=20 > It's a problem that we can handle at the moment, by occasionally = running a first aid script, but I can't imagine that in 6-12 months we = are going to be running WebDNA in the same format as we do now. >=20 >=20 >=20 > TC >=20 >=20 > On 28 Sep 2010, at 14:16, Govinda wrote: >=20 >> Hi Chris! :-) >>=20 >> I have not used MySQL (or other external db) outside of PHP (not yet = with webdna), but I do not see how webdna's future can get around really = strong support of that. Of course it is a royal pain to have to code = outside of webdna's beautiful internal db system, but when the db's get = too large, then it seems just too risky to not have options. Maybe in = some cases it is not even just that webdna could not handle a large db, = but that maybe their is just not enough RAM allotted in some setups. I = have not read much of the articles around the current state of MySQL, = but there is simply so much of it out there, that for all I know it is = still the best option as backup format. (?) >>=20 >> Maybe my very partial knowledge here will prove my lack of thorough = familiarity with the range of server-side considerations, but at least = it will add to getting discussion going. >>=20 >> -Govinda >>=20 >> On Sep 28, 2010, at 8:35 AM, christophe.billiottet@webdna.us wrote: >>=20 >>> Good morning everyone! >>>=20 >>> this email is for WebDNA users working with MySQL. We would like to = know how many of you need MySQL support and the reason why you prefer = using MySQL instead of the internal database system. >>> As you know, MySQL now belongs to Oracle with license restrictions = and we were thinking, in case external database support is necessary, if = a better/faster ODBC support woud not be a more universal idea. We also = gave SQLite a thought, but despite its qualities, the internal WebDNA = database system is more powerful. >>>=20 >>> This is not a trivial matter, so we will listen to everyone. >>>=20 >>> thank you! >>>=20 >>> - chris--------------------------------------------------------- >>> 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 >>> Bug Reporting: support@webdna.us >>=20 >> ------------ >> Govinda >> govinda.webdnatalk@gmail.com >>=20 >>=20 >>=20 >>=20 >> --------------------------------------------------------- >> 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 >> Bug Reporting: support@webdna.us >=20 > --------------------------------------------------------- > 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 > Bug Reporting: support@webdna.us
Associated Messages, from the most recent to the oldest:
Each time a record is added, your database is written to disk. This is = fine except if your database is large and that you get several new = entries every second. WebDNA 7.0 does not anymore write to disk for = every single [append]: There is now (WebDNA 7.0) only three ways for WebDNA to write to disk: - the Administration configuration that says "Automatically commit = databases to disk after modification" - [closedatabase db=3Dname.db] in your template causes the specified = database file (or full path) to be written and closed. This is only = needed for special cases (usually before appending to a file) where you = need to change a file perhaps cached in RAM. - [commitdatabase db=3Dname.db] in your template causes the specified = database file (or full path) to be written but not closed (so it remains = in RAM) I wonder if [spawn][commitdatabase db=3Dname.db][/spawn] could not be = associated with an [exclusivelock]: that would be a way to flush the db = once in a while without any speed loss.... we will have to test this. - chris On Sep 28, 2010, at 10:45, Toby Cox wrote: > I hadn't thought of this, but now that I think of it we also have a = problem with large, heavy traffic, heavy write DBs >=20 > On an ecommerce site we run, one particular db currently stands at = 58,000 records (just over 1Mb) and it has started to corrupt records in = the last 4-6 months. Obviously this is something that tends not to = happen with MySQL. >=20 > High traffic large databases with little writing do just fine, as do = high traffic smaller DBs with lots of writing. We have a record of all = dispatched items that gets written to just a few hundred times a day. = This stands at 167,000 records and 1.2Mb and is just fine. >=20 > Meanwhile, with CakePHP and MySQL we have large DBs (250,000+) that = are written to 1,000+ times per day with no corruption. >=20 > It's a problem that we can handle at the moment, by occasionally = running a first aid script, but I can't imagine that in 6-12 months we = are going to be running WebDNA in the same format as we do now. >=20 >=20 >=20 > TC >=20 >=20 > On 28 Sep 2010, at 14:16, Govinda wrote: >=20 >> Hi Chris! :-) >>=20 >> I have not used MySQL (or other external db) outside of PHP (not yet = with webdna), but I do not see how webdna's future can get around really = strong support of that. Of course it is a royal pain to have to code = outside of webdna's beautiful internal db system, but when the db's get = too large, then it seems just too risky to not have options. Maybe in = some cases it is not even just that webdna could not handle a large db, = but that maybe their is just not enough RAM allotted in some setups. I = have not read much of the articles around the current state of MySQL, = but there is simply so much of it out there, that for all I know it is = still the best option as backup format. (?) >>=20 >> Maybe my very partial knowledge here will prove my lack of thorough = familiarity with the range of server-side considerations, but at least = it will add to getting discussion going. >>=20 >> -Govinda >>=20 >> On Sep 28, 2010, at 8:35 AM, christophe.billiottet@webdna.us wrote: >>=20 >>> Good morning everyone! >>>=20 >>> this email is for WebDNA users working with MySQL. We would like to = know how many of you need MySQL support and the reason why you prefer = using MySQL instead of the internal database system. >>> As you know, MySQL now belongs to Oracle with license restrictions = and we were thinking, in case external database support is necessary, if = a better/faster ODBC support woud not be a more universal idea. We also = gave SQLite a thought, but despite its qualities, the internal WebDNA = database system is more powerful. >>>=20 >>> This is not a trivial matter, so we will listen to everyone. >>>=20 >>> thank you! >>>=20 >>> - chris--------------------------------------------------------- >>> 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 >>> Bug Reporting: support@webdna.us >>=20 >> ------------ >> Govinda >> govinda.webdnatalk@gmail.com >>=20 >>=20 >>=20 >>=20 >> --------------------------------------------------------- >> 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 >> Bug Reporting: support@webdna.us >=20 > --------------------------------------------------------- > 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 > Bug Reporting: support@webdna.us
christophe.billiottet@webdna.us
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:
Emailer setup (1997)
[append] and SSL (1997)
Bug Report, maybe (1997)
Searching multiple Databases (1997)
[WRITEFILE] to create database spider food? (1998)
WebCatalog-NT?'s (1996)
Email notification to one of multiple vendors ? (1997)
Format all of a sudden doesn't work (1997)
WebCat2_Mac RETURNs in .db (1997)
WebCat for mass emailings (1997)
PROTECT/AUTHORIZE (2002)
WebCatalog and WebMerchant reviewed by InfoWorld (1997)
[OT] FTP client (2003)
virtual virtual hosted store.... (1998)
RE: Problem (1997)
Quitting WebMerchant ? (1997)
Stopping NT WebCat service (1998)
Security Issue (1999)
SiteEdit NewFile.html ? (1997)
Image maps/Webcat (1997)