Re: [WebDNA] To Commitdatabase or Not to Commitdatabase

This WebDNA talk-list message is from

2012


It keeps the original formatting.
numero = 108409
interpreted = N
texte = --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Govinda, Thanks for sticking to the thread and helping out... Do you know if is the same as having a at the end of = all/any [append] / [replace] within a codebase. Meaning that they are = equal but absolute better than Flushdatabases. ...or is better than [append] / [replace] or vise = versa. PP On 01/02/2012, at 21.32, Govinda wrote: >> So would a FlushDatabases, which I understand is All DB Written to = Disk be a "slower" task compared to a [commitdatabas....] after every = [replace/append] ? >=20 > I would assume that flushing all databases to disk would be slower. = About [FLUSHDATABASES] the manual says it, "causes all databases to be = written and closed". Why would you want to *close* the database just = to make sure the data is on disk? Then upon the very next operation = that involves that database, you have to load it all back into RAM = again. I would not close the database (remove it from RAM) unless = there was a reason to do so. I would also not commit to disk, nor = remove from RAM, ALL databases at once, unless there was a reason to do = so. =20 >=20 > [COMMITDATABASE..] lets you precisely write to disk (but not flush = from RAM) *just the database you specify*. >=20 >>=20 >> And how do you normally avoid data loss? Are you using the = [commitdatabase...] ?? >=20 > Well my clients are all over the map.. on different hosts, etc. Some = have auto-commit turned on via the admin interface.. Other = times/places I do use [commitdatabase...], specifically, when/where = needed. >=20 > -G--------------------------------------------------------- > 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 --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Govinda,

Thanks for sticking to the = thread and helping out...

Do you know if = <Automatically commit databases to = disk after modification> is the same as having a <commitdatabase = ...> at the end of all/any [append] / [replace] within a codebase. = Meaning that they are equal but absolute better than = Flushdatabases.

...or is = <commitdatabase...> better than [append] / [replace] or vise = versa.

PP



On 01/02/2012, at 21.32, Govinda = wrote:

So would a FlushDatabases, = which I understand is All DB Written to Disk be a "slower" task compared = to a [commitdatabas....] after every [replace/append] = ?

I would assume that flushing all databases to = disk would be slower.  About [FLUSHDATABASES] the manual says it, = "causes all databases to be written and closed".   Why would = you want to *close* the database just to make sure the data is on disk? =   Then upon the very next operation that involves that = database, you have to load it all back into RAM again.   I = would not close the database (remove it from RAM) unless there was a = reason to do so.  I would also not commit to disk, nor remove from = RAM, ALL databases at once, unless there was a reason to do so. =  

[COMMITDATABASE..] lets you precisely write to disk (but = not flush from RAM) *just the database you specify*.


And how do you = normally avoid data loss? Are you using the [commitdatabase...] = ??

Well my clients are all over the map.. on = different hosts, etc.   Some have auto-commit turned on via = the admin interface..   Other times/places I do use = [commitdatabase...], specifically, when/where = needed.

-G---------------------------------------------------------=
This message is sent to you because you are subscribed to
the = mailing list <talk@webdna.us>.
To = unsubscribe, E-mail to: <talk-leave@webdna.us>
archi= ves: http://mail.webdna.us/l= ist/talk@webdna.us
Bug Reporting: support@webdna.us

= --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Kenneth Grome 2012)
  2. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (christophe.billiottet@webdna.us 2012)
  3. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  4. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  5. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  6. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  7. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  8. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  9. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  10. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  11. [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
--Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Govinda, Thanks for sticking to the thread and helping out... Do you know if is the same as having a at the end of = all/any [append] / [replace] within a codebase. Meaning that they are = equal but absolute better than Flushdatabases. ...or is better than [append] / [replace] or vise = versa. PP On 01/02/2012, at 21.32, Govinda wrote: >> So would a FlushDatabases, which I understand is All DB Written to = Disk be a "slower" task compared to a [commitdatabas....] after every = [replace/append] ? >=20 > I would assume that flushing all databases to disk would be slower. = About [flushdatabases] the manual says it, "causes all databases to be = written and closed". Why would you want to *close* the database just = to make sure the data is on disk? Then upon the very next operation = that involves that database, you have to load it all back into RAM = again. I would not close the database (remove it from RAM) unless = there was a reason to do so. I would also not commit to disk, nor = remove from RAM, ALL databases at once, unless there was a reason to do = so. =20 >=20 > [COMMITDATABASE..] lets you precisely write to disk (but not flush = from RAM) *just the database you specify*. >=20 >>=20 >> And how do you normally avoid data loss? Are you using the = [commitdatabase...] ?? >=20 > Well my clients are all over the map.. on different hosts, etc. Some = have auto-commit turned on via the admin interface.. Other = times/places I do use [commitdatabase...], specifically, when/where = needed. >=20 > -G--------------------------------------------------------- > 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 --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Govinda,

Thanks for sticking to the = thread and helping out...

Do you know if = <Automatically commit databases to = disk after modification> is the same as having a <commitdatabase = ...> at the end of all/any [append] / [replace] within a codebase. = Meaning that they are equal but absolute better than = Flushdatabases.

...or is = <commitdatabase...> better than [append] / [replace] or vise = versa.

PP



On 01/02/2012, at 21.32, Govinda = wrote:

So would a FlushDatabases, = which I understand is All DB Written to Disk be a "slower" task compared = to a [commitdatabas....] after every [replace/append] = ?

I would assume that flushing all databases to = disk would be slower.  About [flushdatabases] the manual says it, = "causes all databases to be written and closed".   Why would = you want to *close* the database just to make sure the data is on disk? =   Then upon the very next operation that involves that = database, you have to load it all back into RAM again.   I = would not close the database (remove it from RAM) unless there was a = reason to do so.  I would also not commit to disk, nor remove from = RAM, ALL databases at once, unless there was a reason to do so. =  

[COMMITDATABASE..] lets you precisely write to disk (but = not flush from RAM) *just the database you specify*.


And how do you = normally avoid data loss? Are you using the [commitdatabase...] = ??

Well my clients are all over the map.. on = different hosts, etc.   Some have auto-commit turned on via = the admin interface..   Other times/places I do use = [commitdatabase...], specifically, when/where = needed.

-G---------------------------------------------------------=
This message is sent to you because you are subscribed to
the = mailing list <talk@webdna.us>.
To = unsubscribe, E-mail to: <talk-leave@webdna.us>
archi= ves: http://mail.webdna.us/l= ist/talk@webdna.us
Bug Reporting: support@webdna.us

= --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA-- Palle Bo Nielsen

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[4]: Problem with new formvariables (2000) 100 + Users updating database (2002) Pithy questions on webcommerce & siteedit (1997) ShowCart Errors *FIXED (2000) won't serve .tpl -index.tpl gone, made test.tpl (2000) Group Updates (1998) PCS Customer submissions ? (1997) WebCat .pdf file is still messed up... (2000) Multiple Ad databases? (1997) New Weird Behavior (bug report) (2000) Triggers (1999) Pithy questions on webcommerce & siteedit (1997) More Applescript (1997) What kind of request is this? (2002) WebDNA Examples (Was Suggestions) (1998) Template Encryption (1998) Security Question (1997) Running subtotal? (1998) [OT] Bad Hard Drive? (2003) Help with Repost Data msg from form (1997)