<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Phrases You Should Never See in an FAQ</title>
	<link>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/</link>
	<description>A man needs a little madness, or else he never dares cut the rope and be free. -Nikos Kazantzakis</description>
	<pubDate>Fri, 21 Nov 2008 00:03:41 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: Craig S</title>
		<link>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48839</link>
		<author>Craig S</author>
		<pubDate>Wed, 05 Dec 2007 15:48:15 +0000</pubDate>
		<guid>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48839</guid>
		<description>I think my objection was from the purist in me that dislikes unattended automatic database updates, which is what many people use SchemaUpdate for.  I think the fact that I skipped the point you made about the FAQ answer is that I can see where it is coming from and partly agree.  When you really break it down Hibernate is among the strongest of ORMs.  In that position the developers have certain methods, mindsets and theories along with experience that they must share/communicate.  Having seen far too many projects with a crippled/broken database and persistence tiers I feel guidance is paramount.  Perhaps the phrasing could be a little better but the information must flow.</description>
		<content:encoded><![CDATA[<p>I think my objection was from the purist in me that dislikes unattended automatic database updates, which is what many people use SchemaUpdate for.  I think the fact that I skipped the point you made about the FAQ answer is that I can see where it is coming from and partly agree.  When you really break it down Hibernate is among the strongest of ORMs.  In that position the developers have certain methods, mindsets and theories along with experience that they must share/communicate.  Having seen far too many projects with a crippled/broken database and persistence tiers I feel guidance is paramount.  Perhaps the phrasing could be a little better but the information must flow.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48789</link>
		<author>Jason</author>
		<pubDate>Tue, 04 Dec 2007 23:56:16 +0000</pubDate>
		<guid>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48789</guid>
		<description>Hi Craig,

Disagreement is fine by me :).  However, I think you really missed my point.  I am not having a go at the Hibernate team for the current state of SchemaUpdate.  I understand I am using it in ways that were not intended, and have to expect some problems.  I even say in the post that I don't expect them to jump to implement this feature.  My problem is that they should not be telling me and other users we don't need to do things which we certainly do need to do (like automatically update a production schema).

I also do not understand your point in your discussion about the persistence and database layer.  Hibernate allows me to add index information to my mapping files, in which case the indices are created when using Hibernate to generate a fresh schema (using SchemaExport).  Maybe there another purity argument against this but the fact is that it works well, reduces duplication of information in our app and allows us more easily to support multiple databases.  It is just a shame that even though the information is there and understood by SchemaExport that SchemaUpdate doesn't also use it.</description>
		<content:encoded><![CDATA[<p>Hi Craig,</p>
<p>Disagreement is fine by me :).  However, I think you really missed my point.  I am not having a go at the Hibernate team for the current state of SchemaUpdate.  I understand I am using it in ways that were not intended, and have to expect some problems.  I even say in the post that I don&#8217;t expect them to jump to implement this feature.  My problem is that they should not be telling me and other users we don&#8217;t need to do things which we certainly do need to do (like automatically update a production schema).</p>
<p>I also do not understand your point in your discussion about the persistence and database layer.  Hibernate allows me to add index information to my mapping files, in which case the indices are created when using Hibernate to generate a fresh schema (using SchemaExport).  Maybe there another purity argument against this but the fact is that it works well, reduces duplication of information in our app and allows us more easily to support multiple databases.  It is just a shame that even though the information is there and understood by SchemaExport that SchemaUpdate doesn&#8217;t also use it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig S</title>
		<link>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48773</link>
		<author>Craig S</author>
		<pubDate>Tue, 04 Dec 2007 19:54:01 +0000</pubDate>
		<guid>http://www.alittlemadness.com/2007/12/05/phrases-you-should-never-see-in-an-faq/#comment-48773</guid>
		<description>I have to disagree with you.  The  SchemaUpdate functionality was designed to get people up and running developing their "business logic" quickly... not to be used as a replacement for a DBA, which is what most people use it for.  The Hibernate team tends to get nailed for anything that goes wrong after someone tries to use their product.... e.g. using SchemaUpdate as a crutch.

In your case of needing an index... that has nothing to do with the persistence layer... the layer cannot utilize that information for anything as a query cannot be pre-planned by a client.  The index was a performance improvement in the  database layer only and was thought out by you in a DBA role.

I'm sure that your schema update functionality takes the old schema into account where a framework like Hibernate cannot as it only knows about the current schema.</description>
		<content:encoded><![CDATA[<p>I have to disagree with you.  The  SchemaUpdate functionality was designed to get people up and running developing their &#8220;business logic&#8221; quickly&#8230; not to be used as a replacement for a DBA, which is what most people use it for.  The Hibernate team tends to get nailed for anything that goes wrong after someone tries to use their product&#8230;. e.g. using SchemaUpdate as a crutch.</p>
<p>In your case of needing an index&#8230; that has nothing to do with the persistence layer&#8230; the layer cannot utilize that information for anything as a query cannot be pre-planned by a client.  The index was a performance improvement in the  database layer only and was thought out by you in a DBA role.</p>
<p>I&#8217;m sure that your schema update functionality takes the old schema into account where a framework like Hibernate cannot as it only knows about the current schema.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
