Git cheat sheet
This is my personal Git cheat sheet. It is really a mish-mosh of other resources across the web. Yep, there are a million of them. This one isn’t special, but it is useful to me. If it works for you too, awesome; if not, move on.
create a remote branch from master
git checkout -b branch_name master
git push origin branch_name
delete a remote branch
git push origin :branch_name
switching between branches on your local
git checkout branch_name
merging and tagging a release branch to master
git checkout master
git merge –no-ff release_branch_name
#fix any potential merge conflicts (there should be any) and commit
git tag -a 2010.xxx
merging a feature branch back into development
git checkout development
git merge –no-ff myfeature_branch
git push origin development
(optionally delete the feature branch, git branch -d myfeature_branch)
bug fixing and patching between branches
Depending on where you are working, commit your fix to the appropriate branch
Then use:
git log | less
Find your revision (it should be one the latest ones)
git diff your_revision_hash > /tmp/my_patch (ex. git diff cfbe9041b > /tmp/my_patch)
git checkout branch_you_want_to_apply patch
git apply /tmp/my_patch
continue committing and pushing as you would normally
Aside from merging, sometimes you want to just pick one commit from a different branch. To apply the changes in revision rev and commit them to the current branch use:
note: try patching first, if patching isn’t working well then try cherry picking the revision(s)
git cherry-pick revision_hash
merging release branch hot-fix and bug fixes to development branch
note: Patching and cherry picking are preferred over full merging
git checkout development
git merge –no-ff release_name
stash your changes for later
git stash
find out what is in your stash list
git stash list
apply your stash
git stash apply
clear your stash
git stash clear
notes about your .git/config
You’ll need to make changes to this as often as you contribute to the different number of branches being used for your project. Meaning if you have to commit to the development branch, latest release branch(es), and merge into the master branch – these all need to be in your .git/config file. Here is an example. Notice the rebase = true on the development branch and how it is commented out for the release branch “Alkonost”.
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "development"]
remote = origin
merge = refs/heads/development
rebase = true
[branch "ReleaseBranch"]
remote = origin
merge = refs/heads/ReleaseBranch
rebase = true
Stored Procedure Myth Busters
The debate between developers and DBAs regarding the use of stored procedures is an old one. Most developers I know would rather not use a stored procedure unless absolutely necessary. Don’t get me wrong, when every last bit of code has been optimized and that highly transactional or trafficked portion of your application is still in need of a boost, stored procedures can provide speed and efficiency. My real disgruntlement derives from DBAs that argue for the use of stored procedures for the wrong reasons. The same reasons I hear are actually biased lines of reasoning and aren’t always true. Let me be clear that I am attempting to flush out blanket statements promoting the use of stored procedures when they aren’t needed. My underlying belief is that stored procedures are good tools, just not all the time.
“Stored procedures shield you from change in the database.”
Scenario: Adding or deleting a column
Removing or adding a column to a table can affect the stored procedure signature. A straightforward example of this would be if there was a sproc that inserted comments. Now imagine that business wanted comments, but also the locality of where the person was commenting. You would now have to provide the latitude and longitude to the sproc. This could happen easily if you are re-factoring or adding/removing columns based on new requirements. When this type of change occurs it generally cascades through the application code, the test suite, the stored procedure, QA must test it, and lastly a deployment. It is clear that a stored procedure doesn’t always shield your application from change, in fact, it added an extra step since you not only had to alter the table, but you also had to be sure that you changed the stored procedure.
Scenario: Increasing or decreasing the size of a column
This time the stored procedure signature doesn’t change, but I’ll bet your application has some server side and/or client side validation to notify users about the appropriate limits of the said data type (most likely some varchar/text). Rinse and repeat the last set of steps before a new deployment since the stored procedure hasn’t saved you from change.
Indeed the scenarios mentioned can be failures of when there is a 1:1 mapping between your sproc and table(s), a result of rapid feature development, or just good old re-factoring. Some argue that in “real databases” this doesn’t happen. Bullshit. If this is true and this never happens in your shop, you must have the world’s most robust and flexible design known to man to account for any and all requests from the business. Congratulations, you and your team must piss excellence. I can’t remember a time where I have witnessed the holy grail of database design when this hasn’t occurred in some capacity. The fact is we must agree that this does happen some of the time.
There have been other comments supporting this statement by contending that when sprocs are used properly as a logical model abstraction over the physical one, it helps shield you from change in the database. Admittedly this approach can be a valid one, but sprocs, in my opinion and I’m sure others would agree, are more about the physical model than they are the logical one. I don’t know about you, but I rather perform logical data modeling at the class and/or object level where I can leverage both the behavioral aspects and the data aspects of my domain.
Conclusion
I think the bottom line here is that this shouldn’t be the single criteria for you to make something a stored procedure. My original conclusion on this statement was that it is a myth, but I may have been a bit overzealous to prove a clever article title. It is actually neither true or false, it actually depends on your situation.
“Code related to queries and transactions belongs in the database so make it a stored procedure.”
Let’s first consider this statement from a testability perspective. Is the code and logic inside your sprocs unit tested? Chances are they’re not. Can you confidently assert that your integration test suite covers the possibilities of someone introducing a bug or defect in the code of your sproc to the extent that your CI server will go red? Maybe. I guess what I am getting at is if more of your business logic resided in the application (where it belongs) then the probability and certainty of answering yes to both of these questions would be higher.
Now let’s consider this from a troubleshooting aspect. Let’s say someone mistakenly changes a stored procedure by accidentally messing up an if/else conditional. Your CI server may or may not go red with a broken build, but where are your developers going to look for the problem? By the time someone checks the broken test(s), looks at the application code, sifts through the commit log (Does your stored procedure code get versioned? It should.), the very last place a developer is looking to solve a problem is stored procedure code. If you’re not so lucky to have a broken build, it might pop up in the error log or through some regression testing.
How about the argument that if more than one application uses the database the logic should reside in a stored procedure? I disagree. The fewer applications using the same database the better. Especially since you could have one application provide REST or SOAP services to other applications. This circumvents duplication of code and it also abstracts the notion of the database to the other applications. In fact, some of your REST or SOAP services may use a sproc or two 
Conclusion
I’m calling this a myth. Testability, troubleshooting, and multiple applications aside, I believe that modeling at the class and/or object level should be the preferred approach.
“Stored procedures are a type of SOA”
Stored procedures could be a type of SOA, however, I’m not sure that stored procedures meet all of the SOA definition criteria. Are sprocs loosely coupled? Are sprocs discoverable? Do sprocs enable reuse of logic? Are sprocs fully autonomous? I bet the answers to these questions would vary depending on who you ask. They are composable. They do optimize. They do conform to a service contract. They do encapsulate.
Conclusion
The jury for me is still out on this one. They seem like a crude type of SOA just touching on the outer edges of the definition. Gray areas are abundant.
“Stored procedures provide a good interface between the application and database.”
A good interface to the database provides developers ease and ability through good object design and abstraction where the underlying implementation details are transparent. A good interface decouples you. A decent interface and decoupling to the database would allow you to migrate from one database to the next with less pain. In my experience the more stored procedures and custom code that ends up your database translates in more work when attempting a migration. I’m sure there are plenty of shops that wish they could move away from their current database, but are afraid to because of the number of crusty stored procedures that have built up over the years.
Conclusion
Stored procedures are simply not a good interface.
“Stored procedures allow for finer more granular user permissions.”
If your DBA says it is easier for them to manage permissions on stored procedures instead of granting the appropriate permissions to the user(s) and table(s) for your application, does it make a stored procedure the right choice for a particular operation? If we are going to get into what is easier for whom, let’s discuss what makes things easier for developers (maybe some other time).
Now a couple readers have pointed out that from a security and auditing perspective stored procedures can be a better way to go. This is something I hadn’t considered before and thanks for bringing this up.
Conclusion
Stored procedures can provide finer more granular control and are more secure. But consider if this is a compelling reason to make what you’re working on a sproc? If you’re concerned about auditing – triggers are an excellent way to handle this. If you’re paranoid about the user doing something with table(s) that have sensitive data a stored procedure could a good way to go.
Stored procedures can shield you from an unruly schema or horrible design, but don’t always shield you from change in the database. All of that logic that could end up in a stored procedure try and keep it in your application if you can. Stored procedures are not an interface, nor are they an abstraction to the database. Stored procedures might be a crude SOA, but consider all the better options for an SOA implementation. If your DBA keeps barking about stored procedures in excess, consider the old adage “If the only tool you have is a hammer, you tend to see every problem as a nail”. I’m curious about other stories or hair brain reasons people may have wrongly promoted the use of stored procedures, if you’ve got a good one please comment.
Infrastructure Automation with Chef
By now you’ve at least heard about Chef or perhaps you’ve thought about evaluating it. If you haven’t heard about Chef, no worries, let me explain. Chef is an open source infrastructure automation framework written in Ruby by the guys at OpsCode for developers. In my opinion, OpsCode has hit a grand slam home run on this one and I want to send them a thank you. So the big questions. Why Chef, why another framework, why should you be interested? It boils down to this, developer tooling and infrastructure automation is generally one of the most overlooked areas in software. Let’s be honest, developers never get the appropriate amount of time while working on a project to do this usually because management and stakeholders don’t understand the value it brings to a project. To the business it is totally intangible, or is it? You might have heard complaints about how they hate that it takes so long for a new developer to get setup and hit the ground running. Maybe you’ve gotten complaints about how long, unpredictable, or “manual” deployments have gotten. Perhaps you’ve been wondering how you could rapidly and consistently clone image clusters of servers. Chef makes this dead easy.
The Quick and Dirty
Chef has an organization structure of many cookbooks. Cookbooks are just folders for organization of a particular set of related recipes. Developers write recipes in a Ruby Chef DSL. You can write recipes to do just about anything. Directory creation, library installation, gem installation, file permissions, OS package management can be controlled via the Ruby DSL Chef provides. It gets better. There is probably a recipe or cookbook already written for what you want to do. There are a growing number of Chef cookbooks and recipes shared on Github. Want a Nginx and Passenger recipe? Already written. Want memcached installed? Already written. You name it, chances are there is a recipe waiting for you. Instantly velocity! Now while this is all fine and dandy for most, recipe support across the various flavors of *nix is growing. Right now there is fantastic cookbook and recipe support if you’re running a Debian, Ubuntu, CentOS, or RedHat Linux. If you’re running another flavor of *nix, it is really easy to do whatever you want. Chef bends and flexes to your needs. Anything you can do with the Ruby language can be used to your advantage while writing a recipe. That reminds me, I’ve got a sweet CentOS recipe for Nginx installation that I have to contribute. Without rambling further you can get the most up to date information on the Chef wiki.
Common Uses
Writing a recipe for developer machine setup is a breeze and you actually can use the Chef gem that comes with the chef-solo command to kick off the recipe.
Are you still using some sucky deployment tool or script written a million years ago? Maybe you’re using Capistrano. Try out the Chef “deploy” resource. The Chef deploy resource by default encapsulates all of the best practices for Rails deployment, it doesn’t get simpler than this. Capistrano was an excellent tool for it’s time, you must try deployment on Chef. It makes rollbacks a snap also. Not using Rails or have some custom deployment requirements? The deploy resource is still awesome. You can pick and choose what you want and configure whatever customizations you need.
Take deployment and rollback even a step further with a tool like Hudson or TeamCity. Configure a job for them to run and wire up the Chef deployment script. The “easy button” deployment and rollback.
Chef combined with some server virtualization management tool you could easily image and setup a whole cluster of servers.
Still not convinced? Community adoption is growing fast and some of the most popular hosting companies in the Ruby sphere of influence are already using Chef. In fact, EngineYard uses Chef for application deployment on their cloud platform.
Bright Future for Dynamic Languages
I find myself fascinated by the increasing popularity of dynamic languages. For many of us dynamic language introduction came by way of Ruby, Python, and/or Javascript. While my fascination with these languages hasn’t ended, I am more enthralled with dynamic languages whose strength is concurrency. Indeed, these are exciting times and there is a shift happening in the software community. Honestly, who hasn’t bragged on Twitter that they just finished reading the latest book on Clojure or Erlang? Clearly there is momentum and change in the air. The future of software and computing in the next 10 or 15 years is being shaped and molded with the underlying fundamentals and principles of these languages.
I’m excited about the evolution happening. There is a higher degree of maturity, professionalism, and most importantly scientific and mathematical infused creativity. We’ve all heard the anecdotal comparison of a craft like architecture versus software. Yes software as a craft is merely a fetus when compared to architecture. For centuries architecture has used equal parts science and artistry to build some of the most breathtaking sites in the world. I believe the software community has really begun using more scientific and mathematical backed artsy creativity. We must flex both sides of our brains to imagine the crazy, the impossible, and make it reality. I digress…back to the languages.
Why am I so fascinated? The bottom line is we are evolving and learning.
- Language composition and leverage
- Developer productivity
- Functional programming and concurrency
Clojure and JRuby both run on the JVM. Undoubtedly there are statistics somewhere showing that Java is one of the most popular languages of our time and it is probably running in your software shop in some capacity. As a result the barrier to entry for integrating and using these new languages has been lowered. It is comparatively easier than the transition when Java gained über popularity in the 90′s. However, this isn’t as important and _fascinating_ as how these languages integrate directly with the Java language. The number of possibilities for composing and leveraging preexisting Java libraries with these languages seems endless. This eliminates many reasons to reinvent a library or API. When you wish you could use some Java component, framework, or API, you can – easily! I’ve used this fact to my advantage using JRuby numerous times. The other really neat possibility that I haven’t messed around with yet is using Clojure in JRuby.
The next reason for my interest is directly related to why Ruby is hot and will remain so for a long time. On a side note, I feel the need to disclose that I am not a Ruby “fan boy”, I’ve spent my time in the ranks wrestling with C and Java and still have an fond appreciation for both. Back to what is important, developer productivity. Here are some of the things these dynamic languages really excel in, while keeping in mind that correlation doesn’t imply causation:
- It will make your developers happy to write less elaborate wordy boilerplate code
- Writing less boilerplate code usually results in writing more human readable and elegant code (it has been said before that code should be human readable first and just coincidentally interpreted by a machine)
- More human readable code can improve maintainability, health, and longevity of the code base
- Maintainability can result in greater agility to output more business value
Mathematicians have been joking that they’ve known that functional programming rocks for a pretty long time now. How could they not? Functions are the premise of their craft. It is true they’ve been using Lisp, Sage, and Python for years. I remember my MCS professors telling us in the late 90′s and early 2000′s that we better learn why these languages are kick ass (all the while they were teaching us the principles of OOP with this new language called Java). In fact, I noticed the other day that the new course outlines for MCS students at UIC have plenty of functional programming aspects using Python and Lisp. Sure Python isn’t a purist’s functional language, but anything with support for closures will do. Joining the bandwagon, I am trying to get good with Clojure at the moment with the trusty Pragmatic Programming Clojure book at my side. I am not going to lie, it has been tough to wrap my head around this concept (but doesn’t that generally happen with anything outside your comfort zone?). I would be remiss if I didn’t mention Erlang or Haskell in the context of popular functional languages. I suppose I could of chosen either one of those. I felt like Clojure was a better fit for me since it runs on the JVM, it’s dynamic, and the application of my learnings would be easier to integrate at work. So I have written fewer lines of code and as a result things are just concise. I am not sitting there worrying about immutability and concurrency they are just the fruits of my labor. As I finish writing this post, Uncle Bob has been tweeting all week about monads and Clojure so I know I’m on the “right track”. I hope to extract some of the cool ideas out of the O’Reilly Collective Intelligence book and write them in Clojure.
I’m definitely stoked about the future with these languages. There is certainly so many possibilities and cool things to come. So the question is what will you be doing with these languages or more importantly the community?
JRuby, ActiveRecord, JDBC to SQL Server
I recently had to figure out a good way to export data in XML form from a SQL Server database. I searched high and low for a good ActiveRecord adapter written in pure Ruby to talk to SQL Server. Unfortunately, the setup and overhead to get the right ODBC driver, DSN configs, and all those funky libraries to work properly on any *Nix-based machine were adding up way too quickly and complicating matters. So back to the drawing board.
RESTful service from .NET – no
Way too much work for such a simple task that only runs but once a week. Beside anything Microsoft is my nemesis and I am not even going to put my toe in that water.
SQL Server bcp export – no.
The bottom line – writing code in your database is always bad news. Sure the bcp export is the quick and dirty, but it might be too quick and dirty. It can make upgrades and migrations almost impossible. Just think how difficult it would be to migrate from SQL Server to say MySQL if the use of the bcp utility compounds over time. More importantly, how do you test it?
JDBC – yes!
Really? I was kind of shocked to learn that Microsoft jumped on the Java bandwagon and wrote a JDBC adapter. Woo-hoo! Wait…I don’t want to write a bunch of junky DAO’s in Java.
Enter – my good friends JRuby and ActiveRecord.
I can write sweet sugary Ruby code while utilizing the power of any or all of the existing Java libraries – which so happens to include JDBC!
So in order to glue this together it is quite simple.
- First install JRuby, it’s simple and there are 2 million blog posts about how to do this, all you need is Java pre-installed on your machine. Download it here from here.
- jruby -S gem install activerecord
- jruby -S gem install activerecord-jdbc-adapter
- Download the SQL Server JDBC driver JAR, I recommend getting version 2 or higher
- activerecord-jdbc-adapter is a nifty JRuby specific gem that acts as an adapter for ActiveRecord to speak JDBC (yet another thanks to Nick Sieger).
Once your have these things installed you can write a simple Ruby class to establish the connection and define any number of ActiveRecord classes to map to the tables you’re after. Here is a small snippet on how easy it is to connect to SQL Server using this technique.
#assuming this file is inline with your sqljdbc.jar or just put it into your $JRUBY_HOME/lib directory require 'rubygems' require 'active_record' require 'active_record/connection_adapters/jdbc_adapter' require 'sqljdbc.jar' config = {:url => "jdbc:sqlserver://localhost;databaseName=sucky_sqlserver_db", :adapter => "jdbc", :username => "user", :password => "pass"} ActiveRecord::Base.establish_connection( config ) class Person < ActiveRecord::Base; end people = Person.find(:all) ActiveRecord::Base.clear_active_connections! file = File.new("my_xml.xml", "w") file.write(people.to_xml) file.close
Approximately 10 lines of actual code and you’re done. It can’t be done any more elegant or simple than that. Here is the really beauty part, you can actually test your “script”. Use RSpec or TestUnit, but it is tested! Let cron or whatever scheduling mechanism of your choice run your script with confidence
Getting Started With Processing.js Tutorial
This past week I’ve had the opportunity to really dig in and give processing.js a work out. For those not familiar with the technology, processing.js is a JavaScript library based on the Java based processing library available for download at http://dev.processing.org/. Processing.js uses the HTML5 Canvas element to draw shapes and designs while using a similar API to the one defined by the Java library.
I found the barrier to entry was unnecessarily frustrating due to the lack of a _good_ beginners tutorial calling out common pitfalls. But don’t let this sway you, because once you move past this, it is really fun.
Here are the things they don’t tell you about getting started.
- You should download the basic examples zip from the their site.
- You’ll want to grab the processing.init.js and the processing.js from the zip or tarball to include on your page.
- As you begin coding you must tag any processing.js script on your page with
<script type=“application/processing”> //your script here </script>
- You must have a corresponding
<canvas width=“200px” height=“200px”></canvas>
tag after your script in order for it to render the drawing. Make height and width whatever size you’d like.
- Another note is that you can have multiple canvases on your page, you’re not limited to one.
- The processing.init.js looks for
<script type=“application/processing”></script>
tag on your page and performs the processing.js initialization, if you don’t have this included on your page nothing will be drawn.
- An alternative to using the processing.init.js and <script type=”application/processing”></script> is to use the datasrc attribute on the canvas tag.
<canvas datasrc=”your_processing_script.js”></canvas>
These are just some of the things I ran into and I hope this helps anyone trying to get started with processsing.js. Next time I will post something using the processing.js library.
Rails 2.3.3 to 2.3.5 and Jruby 1.4 Upgrade Notes
Rails upgrade notes:
1.) Rails now has seeding functionality and along with it comes a new task, db:seed. If you use the seed_fu gem be aware that your db:seed call that worked with the gem is now executing the Rails version of db:seed. You will need to call rake db:seed_fu to get the gem version to work.
2.) ActiveSupport::JSON::ParseError no longer exists, so be sure to use ActiveSupport::JSON.parse_error.
3.) Update your rspec and rspec-rails gems to 1.3.x.
4.) Update your rack gem from 1.0.0 to 1.0.1
5.) Rails 2.3.5 works with the RailsXss plugin, in Rails 3 escaping content in erb will default, but if you want to ensure your site isn’t at risk of XSS, make sure you do this install.
Jruby upgrade notes:
If you are using Jruby < 1.4 and you use the net/http library, you better upgrade soon. We were having all sorts of problems with threading and exorbitantly long running requests. There were several bug fixes around the open and read timeout functionality in Jruby 1.4. Now network requests will timeout properly according to your open and read timeout settings.
Session Store Strategy Using Memcached
It is becoming increasingly popular to mix technologies, frameworks, and languages to power a web site. So what happens when you want to share session data between some permutation of a Ruby, PHP, .NET, Python, Java web framework? Well of course using cookies is the first thing that should pop into your head, and with good reason, that is the way it ought to be. It should be as simple and stateless as possible. However, we all know that many applications store objects in their sessions and that makes it impossible to use cookies. What are your options?
Option 1:
Buckling down and incurring the cost of simplifying all of your session data suitable for cookies is one option, but tricky and difficult to do for many applications storing objects in session.
Option 2:
You might consider some RESTful SOA to talk between your variable stack of frameworks, but the cost of doing that is two fold. First, you must consider the security constraints of how the services would be consumed and restrict that to internal consumption to prevent leaking sensitive data. Second, it would increase the chattiness between the apps which could negatively impact performance if not done just right.
Option 3:
Storing session data in a shared database? Eh, no. Locking and transactional problems of a database shared between many applications is a recipe for disaster.
Option 4:
Memcached! OK, hear me out on on this one. Here are some of the advantages of using Memcached:
a.) Distributed high availability server
b.) Zero cross communication between the various applications for session data
c.) Memcached can support serialized objects, XML, YAML, and basically whatever
d.) Legacy application session stores can continue working almost the same only with a new hook to save and retrieve shared session data
e.) Memcached server cluster can be setup behind your firewall reducing any possibility of leaking sensitive session data to the outside world
f.) Minimizing complexity of security implementation (ie if a service based approach were used for cross-app session communication through services == more overhead)
g,) Chances are if you are using Ruby, PHP, or Python you already have Memcached as part of your architecture and if you don’t then it is a double bonus because of the added benefits that are yet to be realized for the new power of caching at your fingertips.
So here are some disadvantages:
a.) The language(s) your are using don’t have any open source support for communication with Memcached yet and you aren’t ready to incur the cost of developing it yourself
b.) Your organization prevents the use of this technology for whatever crazy reason
c.) Some will contend that if the Memcached server crashes your session data will be lost (same deal when your application servers crash though)
There are probably more disadvantages, but I am here promoting the use of Memcached so it is a little biased. Here are some visualizations of this idea. I put together a flow and sequence diagram. The underlying concept is that the all of the applications would need to read and write to a common cookie representing the key to look up the session data from Memcached.
Memcached Session Store
magic_meta_methods
Update: I’ve made magic_meta_methods a gem available at http://rubygems.org/gems/magic_meta_methods
A while back I wrote a plugin for Rails that serializes text and data structures into a singular column called magic_meta_methods on an ActiveRecord. The plugin then makes the data readable and writable through meta-programmed methods and allows the user to save the ActiveRecord just as they would if they were modifying regular attributes. I’ve found this particularly useful for when there isn’t a need to store data that has to be queried or when you want to keep a data structure in tact like an array or hash. By reducing the number of columns and clutter on the table, you can keep the migrations to a minimum. As always I like to hear what the community thinks about it, or what types of improvements would make it more useful.
Rails Lectures at Depaul
Last semester at Depaul University I had the opportunity to give 2 lectures on Ruby on Rails. The topics were “Rails Hosting & Deployment” and “Rails Security”. It was an awesome experience and really rewarding to talk about something that I am passionate about. A big thanks to Igor Polevoy who introduced and recommended me to the Depaul staff.
Here is a copy of the PowerPoint I used on the lecture for Rails Hosting & Deployment.
jruby-quartz 1.1 released
Update: jruby-quartz is a gem at http://rubygems.org/gems/jruby-quartz
I just released jruby-quartz 1.1 on github. Notable changes include support for programmatically firing a job from the base job scheduler instead of relying solely on the scheduled job pool. As a side note, I just realized that github has temporarily stopped building gems since they’ve moved to Rackspace. So if you’re looking to use gem install, you are out of luck until they re-write that system.
MySQL fix for activerecord-jdbc-adapter 0.9.2
About 2 months back I was working on getting a db dump on my current project. I noticed a bunch of the primary keys were missing from tables in the dump file. Irked, I observed that many of tables we hook up to have residual Java Hibernate-isms with non-standard primary keys, basically not ‘id’.
After some digging I found a little problem with activerecord-jdbc-adapter, so I submitted a patch. The good news is that my patch has been included in the latest release. Thanks to Nick Sieger and the gang for including it.
== 0.9.2- The main, highly awaited fix for this release is a solution to therake db:create/db:drop issue. The main change is a new 'jdbc' railsgenerator that should be run once to prepare a Rails application touse JDBC. The upside of this generator is that you no longer willneed to alter database.yml for JDBC. See the README.txt for details.- Cleanup and reconnect if errors occur during begin/rollback(Jean-Dominique Morani, Christian Seiler) ...- Fix for mysql tables with non standard primary keys such that the schema dump is correct (Nick Zalabak)
Follow me on Twitter
My github repository
My LinkedIn Profile