HTML::Template

On Tue, 10 Aug 2004, David Wheeler wrote:

> eWeek has reviewed Bricolage, the mod_perl-powered,
> HTML::Template-supporting, PostgreSQL-backed open-source content
> management system. The article was published last week. An excerpt:

And if you like the sound of Bricolage, you're gonna really like
Krang!  Not only does it also support HTML::Template, it was built
with HTML::Template.  Check it out:

  http://krang.sf.net

Here's a comparison of Krang and an older version of Bricolage:

  http://krang.sf.net/docs/krang_vs_bric.html

-sam

PS: Yup, this is still my list.  ;)

On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote:

> Here's a comparison of Krang and an older version of Bricolage:
>
>   http://krang.sf.net/docs/krang_vs_bric.html

Make that an _ancient_ version of Bricolage. So ancient that the 
comparison is far from accurate and no longer really relevant.

Cheers,

David

On Wed, 11 Aug 2004, David Wheeler wrote:

> On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote:
> 
> > Here's a comparison of Krang and an older version of Bricolage:
> > 
> >   http://krang.sf.net/docs/krang_vs_bric.html
>
>  Make that an _ancient_ version of Bricolage. So ancient that the
> comparison is far from accurate and no longer really relevant.

Patches welcome.  It's a pretty old version of Krang too, actually!

-sam

"Sam Tregar" <sam@...> wrote in message
news:Pine.LNX.4.61.0408111204200.8801@......
> On Wed, 11 Aug 2004, David Wheeler wrote:
>
> > On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote:
> >
> > > Here's a comparison of Krang and an older version of Bricolage:
> > >
> > >   http://krang.sf.net/docs/krang_vs_bric.html
> >
> >  Make that an _ancient_ version of Bricolage. So ancient that the
> > comparison is far from accurate and no longer really relevant.
>
> Patches welcome.  It's a pretty old version of Krang too, actually!
>
> -sam
>
I noticed a couple of things from the site. I don't see it working on
Windows using Apache? Is this possible? Also it seems to be MySQL specific.
Did I read that wrong?

Robert

On Wed, 11 Aug 2004, Robert wrote:

> I noticed a couple of things from the site. I don't see it working on
> Windows using Apache? Is this possible?

Yes, and of course.  Very little software written for Unix-esque
systems (like Krang and Bricolage) works on Windows.  I don't see any
reason why it couldn't be made to work on Windows, but I see very
little reason to do so!

> Also it seems to be MySQL specific.  Did I read that wrong?

Nope, you got that right too.

-sam

On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote:
> > Also it seems to be MySQL specific.  Did I read that wrong?
> 
> Nope, you got that right too.

Out of interest, why MySQL? I know that lack of Postgres support is one
reason that we didn't consider Krang recently when looking for a content
management system recently.

Not trying to start a flame-war. Were there technical reasons, or was it
a "I have time to make it work well with on database" thing?

Chisel
-- 
e:   chisel@...      |        Opinions are like arseholes -
w:   http://www.herlpacker.co.uk/ |               everyone has one
gpg: D167E7FE                     |

On Aug 11, 2004, at 3:56 PM, Sam Tregar wrote:

> Yes, and of course.  Very little software written for Unix-esque
> systems (like Krang and Bricolage) works on Windows.  I don't see any
> reason why it couldn't be made to work on Windows, but I see very
> little reason to do so!

I expect that Bricolage will be ported to Windows shortly after 
mod_perl 2 ships with robust thread support (which is unlikely in 
2.0.0), especially now that PostgreSQL 8.0 will be Win32 native.

Regards,

David

On Thu, 12 Aug 2004, Chisel Wright wrote:

> On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote:
>>> Also it seems to be MySQL specific.  Did I read that wrong?
>>
>> Nope, you got that right too.
>
> Out of interest, why MySQL? I know that lack of Postgres support is one
> reason that we didn't consider Krang recently when looking for a content
> management system recently.

Really?  Can you explain why MySQL vs. Postgres was a deal-breaker?  And 
out of curiosity, what were the other reasons?  Since noone chooses a CMS 
lightly (it really is a long-term decision), I'd really love to know. 
Besides, we're always looking for ways to improve Krang!

>
> Not trying to start a flame-war. Were there technical reasons, or was it
> a "I have time to make it work well with on database" thing?
>

Phew.  And to quell any thoughts in the wings, yes, you can work on Krang 
in both emacs and vi.  Or any other editor for that matter (yes, nano 
folks too!).

Simply put, we started developing Krang to serve our own needs, and MySQL 
fit our needs better than Postgres did.  We open-sourced it as a way to 
give back to the community, and if people want support for other DB's, 
they're welcome to contribute.  :)

On Wed, 11 Aug 2004, David Wheeler wrote:

> I expect that Bricolage will be ported to Windows shortly after mod_perl 2
> ships with robust thread support (which is unlikely in 2.0.0), especially now
> that PostgreSQL 8.0 will be Win32 native.

Really?  I wonder why anyone would bother!

-sam

On Thu, 12 Aug 2004, Chisel Wright wrote:

> On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote:
> > > Also it seems to be MySQL specific.  Did I read that wrong?
> > 
> > Nope, you got that right too.
> 
> Out of interest, why MySQL? I know that lack of Postgres support is one
> reason that we didn't consider Krang recently when looking for a content
> management system recently.

That's too bad.  I'm not sure why you'd care which database your
content-management system was running on.  In most cases you'll hardly
notice unless it breaks, and I'd warrant that MySQL is a heck of a lot
less likely to break than PostgreSQL!

> Were there technical reasons

MySQL is, in my opinion, the best free database.  It's definitely
better than PostgreSQL and I should know, I spent more than a year and
a half working with it on the Bricolage project.  Of course, how one
defines "better" is subjective.  Here are a few observations that come
to mind:

  - MySQL is more stable.  The developers of MySQL do an absolutely
    amazing job vetting new releases before they're declared stable.
    I encountered exactly one bug in MySQL while developing Krang.
    Just one!  I don't have enough fingers to count all the bugs I saw
    in PostgreSQL while working on Bricolage.

  - MySQL is faster and easier to optimize when it's running slow.
    Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
    ANALYZE run-around.

  - MySQL is easier to master and harder to abuse.  The set of
    supported commands is much smaller than most databases.  That
    means it's harder to end up with a rat's nest of a database
    schema.  Harder, but of course not impossible!

Now, to be fair, PostgreSQL has a lot of features that aren't present
in MySQL.  I tend to think most of them aren't all they're cracked up
to be, but I understand that a reasonable person can disagree.

> or was it a "I have time to make it work well with on database"
> thing?

Sure, that too.  My constant refrain while I led the Krang's
development was "YAGNI" - You Ain't Gonna Need It.  We definitely
didn't need to support more than one DB, so we didn't.  If someone
wants to come along and add PostgreSQL support, I think that's fine.
I think it's about as likely as someone porting Bricolage to MySQL,
but people talk about that all the time too!

-sam

you are kidding right?

ACID capabilites and all that...
proper locking semantics...
long history with native support for transactions...
proper SQL transaction semantics...

As you said, people can make spaghetti out of anything - how this makes =
MySQL 'better', I dont understand.

Mathew


> > > > Also it seems to be MySQL specific.  Did I read that wrong?
> > >=20
> > > Nope, you got that right too.
> >=20
> > Out of interest, why MySQL? I know that lack of Postgres support is =
one
> > reason that we didn't consider Krang recently when looking for a =
content
> > management system recently.
>=20
> That's too bad.  I'm not sure why you'd care which database your
> content-management system was running on.  In most cases you'll hardly
> notice unless it breaks, and I'd warrant that MySQL is a heck of a lot
> less likely to break than PostgreSQL!
>=20
> > Were there technical reasons
>=20
> MySQL is, in my opinion, the best free database.  It's definitely
> better than PostgreSQL and I should know, I spent more than a year and
> a half working with it on the Bricolage project.  Of course, how one
> defines "better" is subjective.  Here are a few observations that come
> to mind:
>=20
>   - MySQL is more stable.  The developers of MySQL do an absolutely
>     amazing job vetting new releases before they're declared stable.
>     I encountered exactly one bug in MySQL while developing Krang.
>     Just one!  I don't have enough fingers to count all the bugs I saw
>     in PostgreSQL while working on Bricolage.
>=20
>   - MySQL is faster and easier to optimize when it's running slow.
>     Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
>     ANALYZE run-around.
>=20
>   - MySQL is easier to master and harder to abuse.  The set of
>     supported commands is much smaller than most databases.  That
>     means it's harder to end up with a rat's nest of a database
>     schema.  Harder, but of course not impossible!
>=20
> Now, to be fair, PostgreSQL has a lot of features that aren't present
> in MySQL.  I tend to think most of them aren't all they're cracked up
> to be, but I understand that a reasonable person can disagree.
>=20
> > or was it a "I have time to make it work well with on database"
> > thing?
>=20
> Sure, that too.  My constant refrain while I led the Krang's
> development was "YAGNI" - You Ain't Gonna Need It.  We definitely
> didn't need to support more than one DB, so we didn't.  If someone
> wants to come along and add PostgreSQL support, I think that's fine.
> I think it's about as likely as someone porting Bricolage to MySQL,
> but people talk about that all the time too!
>=20
> -sam

On Thu, 12 Aug 2004, Mathew Robertson wrote:

> you are kidding right?

Not at all.  That doesn't mean I expect to convince anyone though.
This is the kind of wisdom that usually only comes from experience!

> ACID capabilites and all that...
> proper locking semantics...
> long history with native support for transactions...
> proper SQL transaction semantics...

Over-rated.  Sure, if I was building banking software I might have a
different opinion, but I'm not.  A simple database with few critical
bugs protects my data better than your fancy ACID transactions!

How can I be so sure?  I've worked with big complex systems running on
both databases.  I've watched Bricolage completely destroy user data
despite using PostgreSQL's transaction support.  In contrast, Krang
hasn't lost data yet, as far as I know.  A few careful locks in the
right places seem to be just what the doctor ordered for a moderatly
complex content management system.  And if the catastrophic happens,
like a system crash, that's what nightly backups are for.  Nightly
backups might not be good enough for all applications, but they're
good enough for a content-management system.

> As you said, people can make spaghetti out of anything - how this
> makes MySQL 'better', I dont understand.

Experience.  Wrestle with a database strewn with triggers,
constraints, abstract types and functions sometime.  You'll be begging
to be back in the moderate mess of a badly designed MySQL DB.  There's
less there so there's just less to do badly.  It may not be an
emperical fact, but I didn't presented it as such!

-sam

On Aug 11, 2004, at 7:09 PM, Sam Tregar wrote:

>> I expect that Bricolage will be ported to Windows shortly after 
>> mod_perl 2
>> ships with robust thread support (which is unlikely in 2.0.0), 
>> especially now
>> that PostgreSQL 8.0 will be Win32 native.
>
> Really?  I wonder why anyone would bother!

Ch-ching. ;-)

Also, read the eWeek review.

Regards,

David
-- 
David Wheeler
President, Kineticode, Inc.
http://www.kineticode.com/
Kineticode. Setting knowledge in motion.[sm]

On Aug 11, 2004, at 9:04 PM, Sam Tregar wrote:

> MySQL is, in my opinion, the best free database.  It's definitely
> better than PostgreSQL and I should know, I spent more than a year and
> a half working with it on the Bricolage project.  Of course, how one
> defines "better" is subjective.  Here are a few observations that come
> to mind:
>
>   - MySQL is more stable.  The developers of MySQL do an absolutely
>     amazing job vetting new releases before they're declared stable.
>     I encountered exactly one bug in MySQL while developing Krang.
>     Just one!  I don't have enough fingers to count all the bugs I saw
>     in PostgreSQL while working on Bricolage.

To whom did you report them? I don't recall you running into any bugs, 
only features you were used to in MySQL but were missing in PostgreSQL.

>   - MySQL is faster and easier to optimize when it's running slow.
>     Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
>     ANALYZE run-around.

Huh? This is because MySQL doesn't keep statistics, which long term is 
to its detriment.  PostgreSQL 7.4 introduced pg_autovaucuum, and it is 
built-in to the server in 8.0, so now it's a no-brainer.

>   - MySQL is easier to master and harder to abuse.  The set of
>     supported commands is much smaller than most databases.  That
>     means it's harder to end up with a rat's nest of a database
>     schema.  Harder, but of course not impossible!

You also don't get any of the advantages of more advanced databases.

> Now, to be fair, PostgreSQL has a lot of features that aren't present
> in MySQL.  I tend to think most of them aren't all they're cracked up
> to be, but I understand that a reasonable person can disagree.

Yep. But this is old hat for you and me, isn't it? ;-)

> Sure, that too.  My constant refrain while I led the Krang's
> development was "YAGNI" - You Ain't Gonna Need It.  We definitely
> didn't need to support more than one DB, so we didn't.  If someone
> wants to come along and add PostgreSQL support, I think that's fine.
> I think it's about as likely as someone porting Bricolage to MySQL,
> but people talk about that all the time too!

Hrm, so Krang has embedded SQL like Bricolage? Pity. I would certainly 
never do that again.

Regards,

David

On Aug 11, 2004, at 9:50 PM, Sam Tregar wrote:

> How can I be so sure?  I've worked with big complex systems running on
> both databases.  I've watched Bricolage completely destroy user data
> despite using PostgreSQL's transaction support.

You did? Why was there never a bug report? I have not seen Bricolage 
lose data.

> In contrast, Krang
> hasn't lost data yet, as far as I know.  A few careful locks in the
> right places seem to be just what the doctor ordered for a moderatly
> complex content management system.  And if the catastrophic happens,
> like a system crash, that's what nightly backups are for.  Nightly
> backups might not be good enough for all applications, but they're
> good enough for a content-management system.

Well, I think I'll just let that comment stand for itself.

> Experience.  Wrestle with a database strewn with triggers,
> constraints, abstract types and functions sometime.  You'll be begging
> to be back in the moderate mess of a badly designed MySQL DB.  There's
> less there so there's just less to do badly.  It may not be an
> emperical fact, but I didn't presented it as such!

But this is typical of the difference between a software developer and 
a DBA. I think that one of the main reasons that MySQL is so popular is 
that developers like it, because they don't have to think about DBA 
issues.

Hrm, I could say more, but we're pretty off-topic here. I'll hold my 
tongue now.

Cheers,

David

> > you are kidding right?
>=20
> Not at all.  That doesn't mean I expect to convince anyone though.
> This is the kind of wisdom that usually only comes from experience!

I'll ignore that...

> > ACID capabilites and all that...
> > proper locking semantics...
> > long history with native support for transactions...
> > proper SQL transaction semantics...
>=20
> Over-rated.  Sure, if I was building banking software I might have a
> different opinion, but I'm not.  A simple database with few critical
> bugs protects my data better than your fancy ACID transactions!

:-)

> How can I be so sure?  I've worked with big complex systems running on
> both databases.  I've watched Bricolage completely destroy user data
> despite using PostgreSQL's transaction support.  In contrast, Krang
> hasn't lost data yet, as far as I know.  A few careful locks in the
> right places seem to be just what the doctor ordered for a moderatly
> complex content management system.  And if the catastrophic happens,
> like a system crash, that's what nightly backups are for.  Nightly
> backups might not be good enough for all applications, but they're
> good enough for a content-management system.
>=20
> > As you said, people can make spaghetti out of anything - how this
> > makes MySQL 'better', I dont understand.
>=20
> Experience.  Wrestle with a database strewn with triggers,
> constraints, abstract types and functions sometime.

umm - yes, I do this already... the cluster I am currently involved in =
building is meant to store 100+ billion records... see below...

>  You'll be begging
> to be back in the moderate mess of a badly designed MySQL DB.  There's
> less there so there's just less to do badly.  It may not be an
> emperical fact, but I didn't presented it as such!

My team is currently building a "Parallel query cluster" (eg "PARALLEL =
hash(id) SELECT id,value FROM row_data WHERE some_clause"), such that we =
are building the 'PARALLEL hash(...)' bit.

The idea is that you have a cluster of say 100 nodes, with various =
schema such a foreign keys, etc.  Then you query it from you data =
processing engine...

... given that I have been using databases since I left uni at 24 (I am =
31 now), I'd say that I have enough experience...

We prefer Open Source tools (which is why we use H::T), high reliability =
and high performance -> we chose PostgreSQL over Oracle; MySQL wasn't =
even a consideration...


In any case, I personally think that MySQL is good enough for most =
tasks; and since this is a little off-thread for H::T, I'll now shut my =
big fat trap...

Mathew

On Wed, 11 Aug 2004, David Wheeler wrote:

> To whom did you report them? I don't recall you running into any bugs, only
> features you were used to in MySQL but were missing in PostgreSQL.

On the PostgreSQL mailing-list.  Two that jump to mind which I'm
absolutely sure I reported:

  - pg_dump produces invalid SQL.

  - Indexes don't get used unless you VACUUM ANALYZE your tables.  I'd
    consider documenting this fact in the section on indexes, but it
    would be even better if it would just go away.

If I remember correctly they both got scheduled to be fixed in some
future version.  You could be right that I let some slip and just gave
up after finding workarounds.  That sounds like me, unfortunately!

> >   - MySQL is faster and easier to optimize when it's running slow.
> >     Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
> >     ANALYZE run-around.
> 
> Huh? This is because MySQL doesn't keep statistics, which long term is to its
> detriment.  

Lies!  MySQL certainly does keep statistics.  It just doesn't require
them to get good use out of most out of its indexes.

> PostgreSQL 7.4 introduced pg_autovaucuum, and it is built-in to the
> server in 8.0, so now it's a no-brainer.

That's good.  I didn't mean to imply that PostgreSQL isn't improving.
I just happen to think that MySQL is more stable at present, and that
it has been more stable in the past.

> > Now, to be fair, PostgreSQL has a lot of features that aren't present
> > in MySQL.  I tend to think most of them aren't all they're cracked up
> > to be, but I understand that a reasonable person can disagree.
> 
> Yep. But this is old hat for you and me, isn't it? ;-)

Sure is.  I don't expect to convince anyone who has already made up
their mind.  But if you ask me why I use MySQL then I don't mind
telling you!  If you don't like my reasons, well, what can I do about
that?

> Hrm, so Krang has embedded SQL like Bricolage?  Pity. I would
> certainly never do that again.

The API classes do.  The CGI layer doesn't and neither do the scripts
in bin/.  I find this to be a pretty reasonable setup and easy to
maintain, but I'm sure there are other reasonable ways to do it.

Actually, this was one of the more difficult design decisions I faced
in Krang.  I spent a couple weeks evaluating OO DB wrappers
(Class::DBI, Alzabo, etc).  Ultimately I decided that they weren't
solving any of the hard problems in Krang, but they would add another
layer of complexity.  The results have been good, but I can't really
say with authority what the alternative would have been like.

Unlike MySQL vs. PostgreSQL.  I've been there, I've done that and I
know the score! ;)

-sam

I'm a 

* start with postgres approx 1996
  - it was out there and simple... 

* migrated to mysql (for speed) approx 1998
  - was gazillions of times faster than postgres
    (postgres was slooow for the average transaction)

* migrated back to postgres approx 2000
  - postgres improved vastly in speed (still not as quick as mysql
    ... but that is not its mission)
  - supported constraints and most importantly triggers/foreign keys
    ... i can't live without foreign keys anymore... at all...
    have numerous tables like: 
	- users (has primary key id)
	- plugin developer develops "users_extended" (sets foreign key
          to id with auto-update/delete cascading)
        - plugin developer develops other table dependent on users (id)
        - etc etc etc
    If a user is deleted, all user data from all tables is deleted
    (taken care of by database).

    - This would just not be possible without foreign keys... the
      application would *need to know* about any additional tables being
      added and as such, the update/delete functions would need to be
      updated in the core, making plugin development very cumbersome. 

    - Another fantastic feature is 'transactions'... can't say enough 
      good things about them :-) 

If mysql is "better" because its smaller, why are they suddenly now
starting to support all these features, which no doubt will slow it down
(putting it on par with postgres)... 

Horses for courses i say, but i *currently* like postgres much better
due to its feature set... which enables clean separation and programming
:-) 



On Thu, 2004-08-12 at 15:14, Mathew Robertson wrote:
> > > you are kidding right?
> > 
> > Not at all.  That doesn't mean I expect to convince anyone though.
> > This is the kind of wisdom that usually only comes from experience!
> 
> I'll ignore that...
> 
> > > ACID capabilites and all that...
> > > proper locking semantics...
> > > long history with native support for transactions...
> > > proper SQL transaction semantics...
> > 
> > Over-rated.  Sure, if I was building banking software I might have a
> > different opinion, but I'm not.  A simple database with few critical
> > bugs protects my data better than your fancy ACID transactions!
> 
> :-)
> 
> > How can I be so sure?  I've worked with big complex systems running on
> > both databases.  I've watched Bricolage completely destroy user data
> > despite using PostgreSQL's transaction support.  In contrast, Krang
> > hasn't lost data yet, as far as I know.  A few careful locks in the
> > right places seem to be just what the doctor ordered for a moderatly
> > complex content management system.  And if the catastrophic happens,
> > like a system crash, that's what nightly backups are for.  Nightly
> > backups might not be good enough for all applications, but they're
> > good enough for a content-management system.
> > 
> > > As you said, people can make spaghetti out of anything - how this
> > > makes MySQL 'better', I dont understand.
> > 
> > Experience.  Wrestle with a database strewn with triggers,
> > constraints, abstract types and functions sometime.
> 
> umm - yes, I do this already... the cluster I am currently involved in building is meant to store 100+ billion records... see below...
> 
> >  You'll be begging
> > to be back in the moderate mess of a badly designed MySQL DB.  There's
> > less there so there's just less to do badly.  It may not be an
> > emperical fact, but I didn't presented it as such!
> 
> My team is currently building a "Parallel query cluster" (eg "PARALLEL hash(id) SELECT id,value FROM row_data WHERE some_clause"), such that we are building the 'PARALLEL hash(...)' bit.
> 
> The idea is that you have a cluster of say 100 nodes, with various schema such a foreign keys, etc.  Then you query it from you data processing engine...
> 
> ... given that I have been using databases since I left uni at 24 (I am 31 now), I'd say that I have enough experience...
> 
> We prefer Open Source tools (which is why we use H::T), high reliability and high performance -> we chose PostgreSQL over Oracle; MySQL wasn't even a consideration...
> 
> 
> In any case, I personally think that MySQL is good enough for most tasks; and since this is a little off-thread for H::T, I'll now shut my big fat trap...
> 
> Mathew
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Html-template-users mailing list
> Html-template-users@...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

On Wed, 11 Aug 2004, David Wheeler wrote:

> On Aug 11, 2004, at 9:50 PM, Sam Tregar wrote:
> 
> > How can I be so sure?  I've worked with big complex systems running on
> > both databases.  I've watched Bricolage completely destroy user data
> > despite using PostgreSQL's transaction support.
> 
> You did? Why was there never a bug report? I have not seen Bricolage lose
> data.

You must be blessed.  There's a whole class of data-loss bugs that I
know I reported but neither of us could replicate.  Once we decided
that 1.4.6 was our last upgrade it seemed like a waste of your time to
keep bugging you.  A good example would be stories that can no longer
be edited or published because they've got NULL element__id pointers.
How did they get NULL element__ids?  I have no idea.  I've never been
able to make it happen on my own.  But I know it happens because I've
had to go in and nuke them every so often to get the system publishing
again.

Similar bugs occur with less frequency in the media and category
systems.  Seemingly for no reason at all an object will lose a
critical ID, often in the morass of the member table.  Generally the
only thing to do is to delete it and ask the user to re-enter the
data.  Sometimes it's possible to intuit the missing ID, but that's
definitely not the average case.

My point wasn't to slander Bricolage, just to provide a case where
transactions didn't do much to protect critical data.  In my
experience they're just a tool which can help in unusual
circumstances.  They're no replacement for careful coding and testing.

> > Experience.  Wrestle with a database strewn with triggers,
> > constraints, abstract types and functions sometime.  You'll be begging
> > to be back in the moderate mess of a badly designed MySQL DB.  There's
> > less there so there's just less to do badly.  It may not be an
> > emperical fact, but I didn't presented it as such!
> 
> But this is typical of the difference between a software developer and a DBA.
> I think that one of the main reasons that MySQL is so popular is that
> developers like it, because they don't have to think about DBA issues.

Yeah, you got me.  I'm a developer.  I've never even met a DBA that I
would trust to work on my data (but I haven't met many)!  Maybe
someday when I do I'll have to use the database he likes to work on.
Until then, I choose!  Would it make sense to have it any other way?

-sam

On Aug 11, 2004, at 10:51 PM, Sam Tregar wrote:

> You must be blessed.  There's a whole class of data-loss bugs that I
> know I reported but neither of us could replicate.  Once we decided
> that 1.4.6 was our last upgrade it seemed like a waste of your time to
> keep bugging you.  A good example would be stories that can no longer
> be edited or published because they've got NULL element__id pointers.
> How did they get NULL element__ids?  I have no idea.  I've never been
> able to make it happen on my own.  But I know it happens because I've
> had to go in and nuke them every so often to get the system publishing
> again.

None of Kineticode's customers have reported this problem including 
PIRT. And there are several hundred thousand documents behind that, 
excluding PIRT. I guess you didn't report it because you couldn't 
replicate it. I remember you mentioning it, though.

> Similar bugs occur with less frequency in the media and category
> systems.  Seemingly for no reason at all an object will lose a
> critical ID, often in the morass of the member table.  Generally the
> only thing to do is to delete it and ask the user to re-enter the
> data.  Sometimes it's possible to intuit the missing ID, but that's
> definitely not the average case.

This often isn't possible, because the FK columns are NOT NULL. And 
again, I've only heard about this from you in email threads like this; 
no other Kineticode customer has ever reported a problem.

> My point wasn't to slander Bricolage, just to provide a case where
> transactions didn't do much to protect critical data.  In my
> experience they're just a tool which can help in unusual
> circumstances.  They're no replacement for careful coding and testing.

Yes, well, transactions are no protection from buggy code, regardless 
of your database choice. So we're in agreement. But I've found having 
each Apache request constituting a transaction extremely helpful in 
minimizing data integrity problems.

> Yeah, you got me.  I'm a developer.  I've never even met a DBA that I
> would trust to work on my data (but I haven't met many)!  Maybe
> someday when I do I'll have to use the database he likes to work on.
> Until then, I choose!  Would it make sense to have it any other way?

Yes, it makes sense to become a DBA, to a certain degree.

Okay, no more OT missives from me! I need some sleep.

Regards,

David

On Wed, 11 Aug 2004, David Wheeler wrote:

> None of Kineticode's customers have reported this problem including
> PIRT. And there are several hundred thousand documents behind that,
> excluding PIRT. I guess you didn't report it because you couldn't
> replicate it. I remember you mentioning it, though.

Yeah, I usually don't bother reporting bugs I can't replicate.  That
doesn't make them less real though!

> This often isn't possible, because the FK columns are NOT NULL. And again,
> I've only heard about this from you in email threads like this; no other
> Kineticode customer has ever reported a problem.

True.  I didn't mean to imply that they always became NULL.  In the
case of the member table it's more common that the proper rows just
cease to exist.  Like a category will lose its category group member
link (or whatever that thing is that all categories need one of or
they stop working).

-sam

On Aug 11, 2004, at 11:13 PM, Sam Tregar wrote:

> True.  I didn't mean to imply that they always became NULL.  In the
> case of the member table it's more common that the proper rows just
> cease to exist.  Like a category will lose its category group member
> link (or whatever that thing is that all categories need one of or
> they stop working).

Sounds a bit mystical to me. ;-)

Regards,

David