Comments for A Few More Words http://warren.mayocchi.com Life, Software Development, Creativity: What I care to write about Thu, 27 Oct 2011 21:33:17 +0000 hourly 1 http://wordpress.org/?v=3.1.2 Comment on Building a better BeanProcessor by Beat the Bookstore http://warren.mayocchi.com/2006/09/25/building-a-better-beanprocessor/comment-page-1/#comment-29464 Beat the Bookstore Thu, 27 Oct 2011 21:33:17 +0000 http://www.mayocchi.com/blog/2006/09/25/building-a-better-beanprocessor/#comment-29464 <p><strong>You should check this out…...</strong></p> <p>[...] Wonderful story, reckoned we could combine a few unrelated data, nevertheless really worth taking a look, whoa did one learn about Mid East has got more problerms as well [...]...</p> You should check this out……

[...] Wonderful story, reckoned we could combine a few unrelated data, nevertheless really worth taking a look, whoa did one learn about Mid East has got more problerms as well [...]…

]]> Comment on Agile Database – Part 2: The release problem research by removing fleas from a dog http://warren.mayocchi.com/2006/03/30/agile-database-part-2-the-release-problem-research/comment-page-1/#comment-26730 removing fleas from a dog Thu, 28 Jul 2011 08:09:57 +0000 http://www.mayocchi.com/blog/2006/03/30/agile-database-part-2-the-release-problem-research/#comment-26730 <p><strong>Visitor recommendations...</strong></p> <p>[...]one of our visitors recently recommended the following website[...]…...</p> Visitor recommendations…

[...]one of our visitors recently recommended the following website[...]……

]]> Comment on Agile Database by lucapette http://warren.mayocchi.com/agile-database/comment-page-1/#comment-14774 lucapette Wed, 11 Nov 2009 11:24:37 +0000 http://www.mayocchi.com/blog/agile-database/#comment-14774 <p>Interesting series. I've read them and i liked them :D</p> Interesting series. I’ve read them and i liked them :D

]]> Comment on Agile Database – Part 4: MIGRATEdb (a solution to the release problem) by WQ http://warren.mayocchi.com/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/comment-page-1/#comment-13856 WQ Thu, 03 Sep 2009 18:28:46 +0000 http://www.mayocchi.com/blog/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/#comment-13856 <p>Warren,</p> <p>That's great news. I'm working on a project that try to use this tool. I can help on testing the file option if that could help. I'm really looking forward to it the sooner the better and now is the best.</p> Warren,

That’s great news. I’m working on a project that try to use this tool. I can help on testing the file option if that could help. I’m really looking forward to it the sooner the better and now is the best.

]]> Comment on Agile Database – Part 4: MIGRATEdb (a solution to the release problem) by warren http://warren.mayocchi.com/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/comment-page-1/#comment-13849 warren Thu, 03 Sep 2009 09:19:23 +0000 http://www.mayocchi.com/blog/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/#comment-13849 <p>I have just implemented a file option - sqlaction file="cr_table.sql" . The file could contain many SQL statements which would be finished by ';' and/or a new line with '/'.</p> <p>This should be available in version 0.6 which I will put up in the next couple of days after I do some more testing. (It would also work for tests - sqltest file="sometest.sql" )</p> I have just implemented a file option – sqlaction file=”cr_table.sql” . The file could contain many SQL statements which would be finished by ‘;’ and/or a new line with ‘/’.

This should be available in version 0.6 which I will put up in the next couple of days after I do some more testing. (It would also work for tests – sqltest file=”sometest.sql” )

]]> Comment on Agile Database – Part 4: MIGRATEdb (a solution to the release problem) by WQ http://warren.mayocchi.com/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/comment-page-1/#comment-13837 WQ Thu, 03 Sep 2009 00:07:25 +0000 http://www.mayocchi.com/blog/2006/04/16/agile-database-part-4-migratedb-a-solution-to-the-release-problem/#comment-13837 <p>Warren, I'd like to call a sql script , see cr_table.sql, instead of put the DDL statement in the migrateDB xml file, do you know how this could be done? Thanks</p> Warren, I’d like to call a sql script , see cr_table.sql, instead of put the DDL statement in the migrateDB xml file, do you know how this could be done? Thanks

]]> Comment on JDBC ResultSet Mapper by warren http://warren.mayocchi.com/2006/10/13/jdbc-resultset-mapper/comment-page-1/#comment-13701 warren Fri, 28 Aug 2009 07:58:12 +0000 http://www.mayocchi.com/blog/2006/10/13/jdbc-resultset-mapper/#comment-13701 <p>The source code is up-to-date. Any details the differences?</p> The source code is up-to-date. Any details the differences?

]]> Comment on JDBC ResultSet Mapper by Norival http://warren.mayocchi.com/2006/10/13/jdbc-resultset-mapper/comment-page-1/#comment-13646 Norival Wed, 26 Aug 2009 12:19:01 +0000 http://www.mayocchi.com/blog/2006/10/13/jdbc-resultset-mapper/#comment-13646 <p>Is the source code available on sourceforge updated?. Because I recompile and it behaves diferently as expected. It difers from the JAR available.</p> <p>Tnks</p> Is the source code available on sourceforge updated?. Because I recompile and it behaves diferently as expected. It difers from the JAR available.

Tnks

]]> Comment on Agile Database – Part 1: The release problem by warren http://warren.mayocchi.com/2006/03/29/agile-database-part-1-the-release-problem/comment-page-1/#comment-9370 warren Tue, 14 Apr 2009 12:23:01 +0000 http://www.mayocchi.com/blog/2006/03/29/agile-database-part-1-the-release-problem/#comment-9370 <p>Re: Person_name...what about simple web registations (name + email)?</p> <p>It is a subjective call as to whether a change is a real world refactoring or an omission by the original designer. Some examples from my work:</p> <ul> <li><p>Today I was adding 'ROWDEPENDENCIES' to tables that were not created with that clause (an infrastructure technology change provides for a 'changestamp' feature that was once implemented via custom code).</p></li> <li><p>I have worked regularly with legacy systems that contain overloaded fields similar to the person_name example. Pretty much an anti-pattern now, but still out there.</p></li> <li><p>Adding new features to a system in a second phase of development (features which require a new set of tables).</p></li> <li><p>Altering existing tables to add extra attributes that were not required in initial project iterations.</p></li> <li><p>Changing the length/precision of a field to reflect the latest information (that was not available or expected in the intial design).</p></li> <li><p>Moving from a 1:1 relationship with an attribute (stored in the base table as another column) to a 1:many relationship (stored as an intermediate relationship table). Again this example was due to a change in the intial requirements.</p></li> </ul> <p>It can be (and is) argued that all changes should have been identified completely up-front. However, whatever our approach to software development, change happens. We use our design skills and experience to minimise bad data modelling in any case. When using an adaptive approach like agile, it is also important to have the tools to release a little part of the system and build on it. Change in an agile environment with good data modelling can be as simple as an incremental release of database features.</p> Re: Person_name…what about simple web registations (name + email)?

It is a subjective call as to whether a change is a real world refactoring or an omission by the original designer. Some examples from my work:

  • Today I was adding ‘ROWDEPENDENCIES’ to tables that were not created with that clause (an infrastructure technology change provides for a ‘changestamp’ feature that was once implemented via custom code).

  • I have worked regularly with legacy systems that contain overloaded fields similar to the person_name example. Pretty much an anti-pattern now, but still out there.

  • Adding new features to a system in a second phase of development (features which require a new set of tables).

  • Altering existing tables to add extra attributes that were not required in initial project iterations.

  • Changing the length/precision of a field to reflect the latest information (that was not available or expected in the intial design).

  • Moving from a 1:1 relationship with an attribute (stored in the base table as another column) to a 1:many relationship (stored as an intermediate relationship table). Again this example was due to a change in the intial requirements.

It can be (and is) argued that all changes should have been identified completely up-front. However, whatever our approach to software development, change happens. We use our design skills and experience to minimise bad data modelling in any case. When using an adaptive approach like agile, it is also important to have the tools to release a little part of the system and build on it. Change in an agile environment with good data modelling can be as simple as an incremental release of database features.

]]> Comment on Agile Database – Part 1: The release problem by Steven Macleod http://warren.mayocchi.com/2006/03/29/agile-database-part-1-the-release-problem/comment-page-1/#comment-9320 Steven Macleod Mon, 13 Apr 2009 10:17:04 +0000 http://www.mayocchi.com/blog/2006/03/29/agile-database-part-1-the-release-problem/#comment-9320 <p>Hi, just getting my head around Agile DB development. I am sure your example above is given as a simple example but surely you would have to be really dumb to create a field called Person_Name in the first place. This may appear to be an obnoxious comment, but all the examples I see around Agile refactoring are for refactoring really stupid mistakes, eg breaking 1NF as in this case. It seems from what I have read that the Agile method uses refactoring to solve problems caused by really bad data modelling, whereas Agile should be used to avoid these errors in the first place. </p> <p>I would be interested in your thoughts on this and would be interested in any real world examples of refactoring complex changes that could not have been preconceived at the modelling phase.</p> <p>Regards</p> <p>Steven</p> Hi, just getting my head around Agile DB development. I am sure your example above is given as a simple example but surely you would have to be really dumb to create a field called Person_Name in the first place. This may appear to be an obnoxious comment, but all the examples I see around Agile refactoring are for refactoring really stupid mistakes, eg breaking 1NF as in this case. It seems from what I have read that the Agile method uses refactoring to solve problems caused by really bad data modelling, whereas Agile should be used to avoid these errors in the first place.

I would be interested in your thoughts on this and would be interested in any real world examples of refactoring complex changes that could not have been preconceived at the modelling phase.

Regards

Steven

]]>