I believe they did consider all the tools available related to refactoring.
Couldn't get you by "schema evolution from the scratch". Its gonna be evolve and you have to consider it. From the scratch is not a likely solution. Refactoring goes more like a little change in each transformation. Its like
"If you have better today doesn't mean you had bad yesterday"
Cant remember the exact one . Scott, could you please help me in this?
Joined: Aug 21, 2004
With Schema evolution from scratch I mean, that I don't use an existing tool like Hibernate and care myself for having a consistent schema.
Honestly, I would leave it to the tool suppliers, because they know better than I on how to tackle the schema evolution problem.
Originally posted by Darya Akbari: Honestly, I would leave it to the tool suppliers, because they know better than I on how to tackle the schema evolution problem.
But is that actually true? You are assuming that the data-model can be derived from the object model - but as both serve different purposes both models have to be able to evolve independently and the changes need a decision-making human as a driver.
I hope that it's true . Otherwise Hibernate would have a problem. But as far as I know Hibernate is very well established in world's J2EE community.
Joined: Aug 19, 2005
SchemaUpdate is simply a tool that comes with Hibernate. I suspect that its contribution to Hibernate's overall success (or demise) is relatively minor, People aren't going to stop using Hibernate because of what SchemaUpdate can't do, while other people are still going to start using Hibernate even if SchemaUpdate doesn't work for them.
The tool net.sf.hibernate.tool.hbm2ddl.SchemaUpdate allows an application to bring a schema up to date with the expected schema based on a set of *.hbm.xml files. Typically, this is used to address a situation in which an incremental update to an application requires a relatively minor change, such as a new property.
Tools often only automate simple tasks, which is good for tasks that are repetitive and/or tedious. Tools like refactoring browsers even help the competent developer accomplish refactoring tasks much more quickly. But fully automated refactoring? I don't think so.
Couple of things: 1. I don't remember the exact quote, or where it's from. Sorry. 2. We present full code in the book for implementing the refactorings. One to show how simple it is to implement them (hence removing the excuse that there isn't any tools) and two because the tools aren't there yet (although they're coming). 3. Although Hibernate is a popular tool, it really isn't all that sophisticated (which might be why it's so popular). It's helped to make O/R mapping popular in the J2EE community, but when you start getting involved with more complex projects that go beyond the "a class maps to a table" idea you find that you need something a little more robust. Perhaps Hibernate will evolve, or perhaps it'll remained focused on the current niche that it fills. Time will tell. My advice is to expand your horizons a bit and understand the true nature of O/R mapping, and O/R issues in general (www.agiledata.org will go a long way towards this goal).
Originally posted by Scott Ambler: It's helped to make O/R mapping popular in the J2EE community, but when you start getting involved with more complex projects that go beyond the "a class maps to a table" idea you find that you need something a little more robust.
If it's really that simple to implement and tackle the schema evolution problem why do most people (at least the ones I know ) use a ORM tool
There are some big points that comes into my mind, why I prefer the tool:
Now aren't these reasons enough .
I agree with Scott that knowing more about the issue doesn't hurt :roll: , but to make a conclusion from it that today's tool suppliers aren't better than I (and most of us) in achieving above goals is, in my mind, a step in the wrong direction.
An ORM framework gives you all that for free. So, why on earth should I do it myself .
Darya, I have the vague feeling that when you talk about schema evolution you mean something different than Scott.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Aug 19, 2005
Originally posted by Darya Akbari: ... why do most people (at least the ones I know ) use a ORM tool
Most people use an object relational mapping tool to relieve them of the burden of having to write pages and pages of code to deal with the Object Relational Impedance Mismatch - i.e. a DAO a for every little object or aggregate (I'm fully aware that there are DAOs on top of Hibernate in some of the source samples - however those are empty shells compared what you would have to write in the absence of an ORM layer). With an ORM tool you simply provide the relational to object mapping information via configuration and it does the rest. In more complicated scenarios you will have to supply hand-coded adaptors that the ORM layer can use but even that code is minimal compared to an entirely hand-coded solution.
Hibernate also helps you along with transaction support, including their support of what they call "Application Transactions", managed versioning, detached objects, etc. Hibernate still has some growing to do when it comes to Stored Procedure support. Currently it only supports a limited number of variations for stored function signatures which can make it difficult to integrate it with an existing "stored procedure" layer - stored procedures can be quite a powerful tool for hiding the actual data model from the layers above it (separation of concerns) and competently written stored procedures (which run on the DB server) can be quite a bit more efficient than any code run in an ORM layer or in the application code. This added layer of indirection can also make it easier to refactor the database independently of anything above the stored procedure layer.
Gavin King is quite adamant in "Hibernate In Action" that Hibernate does not free you from the burden of mastering SQL or becoming competent in Data-modeling techniques and your RDBMS in general. The book also talks at length about object-relational-mapping in general to establish the motivation for creating Hibernate in the first place.
Using an ORM tool actual makes some concessions in performance - but in many cases the performance loss is minimal compared to what you gain. So the core motivations for ORM have nothing to do with "updating" or "evolving" a database schema. Hibernate just happened to provide a tool that would quickly update the database schema based on your object mappings. And the modifications that it generates may very well be quite different to the schema modifications that an experienced data-modeler/DBA may make to accommodate the changing persistence needs of applications and the enterprise as a whole.
BTW: the only reference to tools that I saw, was in Pramod Sadalage's article Evolutionary Database Design. The tools referred to are scripts for common database tasks that you write (and test) yourself.