<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Orm on Brave New Geek</title><link>https://bravenewgeek.com/tag/orm/</link><description>Recent content in Orm on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 19 Dec 2012 19:12:36 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/orm/index.xml" rel="self" type="application/rss+xml"/><item><title>The Importance of Being Idle</title><link>https://bravenewgeek.com/the-importance-of-being-idle/</link><pubDate>Wed, 19 Dec 2012 19:12:36 -0600</pubDate><guid>https://bravenewgeek.com/the-importance-of-being-idle/</guid><description>&lt;p&gt;&lt;em&gt;“Practice not-doing and everything will fall into place.”&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;It’s good to be lazy. Sometimes, in programming, it can also be hard to be lazy. It’s this paradox that I will explore today — The Art of Being Lazy. Specifically, I’m going to dive into a design pattern known as lazy loading by discussing why it’s used, the different flavors it comes in, and how it can be implemented.&lt;/p&gt;
&lt;p&gt;Lazy loading is a pretty simple concept: don’t load something until you really need it. However, the philosophy can be generalized further: don’t do something until you need to do it. It’s this line of thinking that has helped lead to processes like &lt;a href="http://en.wikipedia.org/wiki/Kanban_(development)"&gt;Kanban&lt;/a&gt; and &lt;a href="http://en.wikipedia.org/wiki/Lean_software_development"&gt;lean software development&lt;/a&gt; (and also probably got you through high school). Notwithstanding, this tenet goes beyond the organizational level. It’s about optimizing efficiency and minimizing waste. There’s a lot to be said about optimizing efficiency in a computer program, which is why The Art of Being Lazy is an exceedingly relevant principle.&lt;/p&gt;</description></item><item><title>Solving the Referential Integrity Problem</title><link>https://bravenewgeek.com/solving-the-referential-integrity-problem/</link><pubDate>Sat, 01 Dec 2012 13:37:46 -0600</pubDate><guid>https://bravenewgeek.com/solving-the-referential-integrity-problem/</guid><description>&lt;p&gt;&lt;em&gt;“A man with a watch knows what time it is. A man with two watches is never sure.”&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I’ve been developing my open source Android framework, &lt;a href="http://code.google.com/p/infinitum-framework/"&gt;Infinitum&lt;/a&gt;, for the better part of 10 months now. It has brought about some really interesting problems that I’ve had to tackle, which is one of the many reasons I enjoy working on it so much.&lt;/p&gt;
&lt;h3 id="chicken-or-the-egg"&gt;Chicken or the Egg&lt;/h3&gt;
&lt;p&gt;Although it’s much more now, Infinitum began as an object-relational mapper which was loosely modeled after &lt;a href="http://www.hibernate.org/"&gt;Hibernate&lt;/a&gt;. One of the first major issues I faced while developing the ORM component was loading object graphs. To illustrate what I mean by this, suppose we’re developing some software for a department store. The domain model for this software might look something like this:&lt;/p&gt;</description></item></channel></rss>