q = queryNew('id,name');
new Query(dbtype='query', sql='select * from q').execute().getResult();

This code will throw an exception saying "Table named q was not found in memory".  Why?  Because Query is a CFC, and inside a CFC method invocation, you can't see the var-scoped variables from the calling method (nor the variables scope of the calling template).  This is standard CFC behaviour, but is quite different than using the CFQUERY tag.  The workaround is to do this:

q = queryNew('id,name');
qry = new Query(dbtype='query', sql='select * from q')
qry.setAttributes(q=q);
qry.execute().getResult();

That places the 'q' variable into the variables scope of the Query instance, so it can be found by the CFQUERY tag inside the execute method.  Note that this is NOT thread safe!!  If you take this approach, you must create a new Query instance for every thread of execution – you can't pool them.  Normally this isn't a big deal, but that setAttributes call is equivalent to assigning to the variables scope and carries all the lurking problems.

If you like chaining, you can do this (which is functionality equivalent, including the thread safety concerns):

q = queryNew('id,name');
new Query(dbtype='query', sql='select * from q', q=q).execute().getResult();

Here we're just passing the attribute in via the init method, instead of a separate setAttributes call.  Like I said, it's no different in terms of functionality, but it's a lot nicer (I think) in terms of readability and conciseness.

In my opinion, this is sort of broken.  ColdFusion is all about server-encapsulated hacks in encapsulation.  Think about your use of CFQUERY: you just use it, and CF takes care of getting the right database handles and such for you.  It just works.  It's totally unencapsulated, but it just works.  And it's glorious.  The Query CFC has the same characteristics, except for QofQ.  Not that I expect it to change, but I'm of the opinion that the Query object ought to work like CFQUERY in this regard.

Boring stuff first.  Mentor Graphics Corp is the EDA industry leader and makes all kinds of crazy design and simulation software for electrical engineers, and now embedded developers.  If you have a cell phone or a computer, it's almost guaranteed that you're using something which either embeds Mentor IP or was designed/tested/manufactured with the help of Mentor products.  The company is about a billion dollars in annual revenue and publicly traded.  Our team is currently seven application developers plus a designer, a front-end developer, a multimedia guy, a content editor, and a couple of operations people.  Plus Ron, our boss.  We're hiring three more application developers.  The positions are full-time, on-site, in Wilsonville OR.  Blah, blah, blah.

I work in the corporate marketing department (which is weird, but bear with me) on the web services team which is responsible for pretty much all the public-facing web infrastructure for the company.  www.mentor.com is the primary property, but we run the support portal, an internal business intelligence application, corporate blog hosting, and a couple industry journal sites.  We own everything that comes after the business requirements; divisions in the company come to us with business problems, and we spec, architect, implement, and host the solutions.  Despite the fact we're in the marketing department, IT comes to us for expertise.  Our primary platform is Adobe ColdFusion, but we support Groovy, Java, PHP, and Python for different applications where there was a compelling case to not choose a CFML-based solution.

Now the interesting stuff.

There is a formal job description somewhere, but I don't know where, and I wouldn't link to it even if I did.  If you want to work here, you need two things:

• technical competence
• a passion for development

We expect you to be able to not only implement a spec, but also design solutions.  You shouldn't have to be reminded that not everyone speaks English and that clocks around the world don't all say the same time.  You should know why pure functional languages don't have synchronized blocks.  You should have a preference between emacs and vi and be able to articulate in two sentences or less.  You should have commits to some public VCS repository somewhere.  You want to be part of a large non-hierarchical team working on a variety of projects.  You should know what MVCC stands for without looking it up.  You should want to help the six-months-from-now you have less pain, even if it takes a little more work today.  You shouldn't be proficient in all of Java, C#, JavaScript, Python, Ruby, and Lisp.  You should be proficient in at least one of them, and be competent in at least one more, and be able to compare and contrast the merits of the rest.

If that sounds like you, drop me an email at barney_boisvert@mentor.com or bboisvert@gmail.com.  Ron wants a resume, but I want two paragraphs and ~30 lines of interesting code.  Not 40, not 20.

Our hiring process is straightforward: get your info, quick mini-interview via phone, a simple code test, and an on-site interview to meet the team.  Mentor pays competitively, and has exceptional benefits beyond the salary.  Positions are full time, relocation assistance is likely available if you're not in the area – working remote is not an option.  Ron is very reasonable: if you're the right person, he'll go to bat for you/him/me to ensure things work.  Everyone here understands that spending a little cash to get the right people pays off every time.

As is often the case with internet folks, I know a whole lot of people by name and/or handle, but far fewer in person.  So if you see me – I'm the tall, furry guy who isn't Andy Matthews – please say hello.  And as if you didn't need even more incentive, the company I work (Mentor Graphics Corp) for is currently looking to hire a couple more full-time developers out in beautiful Portland, OR.

s = {
  'javaCast' = javaCast('null', 0),
  'json' = deserializeJson('null')
};
structKeyExists(s, 'javaCast'); // false
structKeyExists(s, 'json');     // true
structKeyExists(s, 'missing');  // false
isNull(s.javaCast); // true
isNull(s.json);     // false
isNull(s.missing);  // true

As you can see, there is no difference between null and missing.  However, the null from the JSON gets deserialized not as a null, but as "null" (i.e., the string containing the letters 'n', 'u', 'l', and 'l'). Wait, what?

I don't think there should be any confusion about how contrived this example is.  However, the issue manifests itself any time you're deserializing JSON packets with ColdFusion.  So watch out.

createObject("java", "coldfusion.server.ServiceFactory")
  .dataSourceService.getDatasource("myDSN")

Unfortunately, this doesn't work on Railo, because the result isn't actually a javax.sql.DataSource, it just looks like one (see RAILO-43).  To put that another way, it's duck typed.

Fortunately, Groovy's "fake" interfaces make beating the typechecks fairly trivial (if kind of ugly):

  def rds = variables.my.datasource
  variables.my.datasource = {
    rds.getConnection()
  } as javax.sql.DataSource

The CFSET gets the "datasource" as normal, and then the little Groovy scriptlet simply wraps it with a closure and tells it to pretend to be a javax.sql.DataSource. The game Escape from Tarkov has one important feature: after your death in a RAID, you lose your equipment. To prevent the loss of important equipment in the game, there are special sites with eft roubles you can always get top equipment and kill all pepegas squad. The items you store from needmana will not disappear. There are three types of containers in total. Alpha, Beta, and Gamma. These containers differ in their size. Usually, these containers should store the most important equipment-maps, ammunition, keys, and so on.  In this case we're assuming that the only method on DataSource that will be invoked is getConnection(), which is the usual case.  If you need to support other methods you'd need to go the Map-as-interface route.

Now we can use variables.my.datasource as a javax.sql.DataSource.  Yay!  Unfortunately, you have to use this sort of snippet everywhere you need a DataSource in your Railo apps, but hopefully that'll get fixed.

For more info on Groovy interfaces, the docs are at http://groovy.codehaus.org/Groovy+way+to+implement+interfaces.

It had honestly never occurred to me that someone would actually want to have stuff get to the database without any control over it.  Transactionality is such an ingrained part of my being that the mere thought of writing to the database outside an explicit transaction never even entered my mind.

There have been a number of discussions about transactions on the cf-orm-dev mailing list.  Often prompted by someone mentioning some problem and me jumping down their throats about how they better use transactions.  But here's a very experienced developer who I know full well intimately understands transactionality actually saying with complete honesty that he likes to have it just work.

I'm personally against this approach: if something goes awry your database could well get jacked, and no one wants that.  Though I nearly always apply transactionals via AOP, and both Sean and I agreed that assuming AOP familiarity is unreasonable for people using CF9 ORM.

The conversation quickly moved on from there (I believe Scala was the next topic), but that brief moment of complete surprise stuck in my mind.  I certainly don't claim to know it all, but I know that I have opinions that are not shared by everyone.  However, the dismissal of ACID like that was a shock.  I respect Sean's opinion very much, and while I will continue to wrap all my saves in a transaction, things are clearly not as cut and dried as I think they are.

If you're building a SQL-heavy, procedural application, the database is probably the only place your domain model is represented.  But if you're building an object oriented application, your domain model will also be represented in memory as object graphs.  In almost all cases, a given object graph is only a small slice of your entire domain model, but it is a representation and must be kept consistent.

Here's an example of a very simple domain model consisting of Person and Pet classes, where a Pet has an owner (a Person), and a Person has a collection of Pets:

component Person {
  property name="name" type="string";
  property name="pets" type="array[Pet]";
}

component Pet {
  property name="species" type="string";
  property name="owner" type="Person";
}

Just to reiterate, these are NOT persistent types.  They're simple types for in-memory use only.

So what semantics does this model imply?  Or to rephrase, what invariants does this model carry?  The most important semantic is that the relationship between pets and their owners is expressed from both sides (both classes).  More explicitly stated, the domain model is structured such that if you have a Person you can get their Pets, and if you have a Pet, you can get their owner (a Person).  The implications of this is expressed in these two invariants:

assert pet.owner is null || pet.owner.pets contains pet
assert person.pets.every { pet.owner == person }

The first one states that if a Pet has an owner, that owner's "pets" collection must contain it.  The second one states that every Pet in a Person's "pets" must have that Person set as it's owner.  I'm trying to be really deliberate in spelling this out, because it's really important.

Just for a moment, let's take a detour to the relational database world.  If we were to express this domain model in the database we'd have a Person table and a Pet table, and the Pet table would have a foreign key (likely named 'owner_id') that references the Person table's primary key.  SQL allows us to traverse the relationship expressed by that foreign key in either direction, so both relationships (Person->Pet and Pet->Person) are expressed in a single place (the foreign key column).  Both directions are represented together.  A foreign key constraint (which all RDBMSes support), on the column is doing nothing more than instructing the database to enforce these invariants.  This is all second nature, and we don't even think about it when we use a database to represent our domain model.

Now back to the in-memory representation.  We still need to enforce these invariants, but in memory we have to deal with references (pointers), and references only point in one direction.  That's why we have to have both the 'pets' property (a Person's references to Pets) and the 'owner' property (a Pet's reference to a Person), but in the database we only need one foreign key column (Pet.owner_id).  The relationship between Person and Pet objects is actually expressed in a pair of references.

The problem with this arrangement is that you, in effect, double represent your relationships.  Both invariants must remain true, and since each invariant is represented by it's own reference in the model, you have to synchronize changes to those references.   When you set the owner of a Pet, you must also add that Pet to the owner's "pets" collection.  When you remove a Pet from a Person's "pets" collection, you must also remove the Pet's owner reference.  If you don't keep these in sync, one of your invariants will be false, and that means your domain model is in an invalid/inconsistent state.

When your domain model is in an invalid state, your application falls apart.  Every assumption you make in your application is suddenly unreliable, because they're predicated on your business rules, and your business rules are expressed through your domain model.  An invalid domain model means your business rules were violated, and anything you do from this point forward will be suspect.  I'm going to say it again: this is really important.  If your domain model is in an invalid state, your application has failed.  Period.  End of story.  Your only recourse is to revert it back to it's last known consistent state and throw away all pending operations.

What about relationships that are not bi-directional?  For example, perhaps your model has PrivateEye and Subject types.  Clearly the PrivateEye needs to know about his Subject, but it'd be kind of silly if the Subject knew about the PrivateEye.  In this case the relationship only moves one way, so there is only one reference (from PrivateEye->Subject), and there is no invariant.  When we put this in the database, however, we have exactly the same structure as the bi-directional Person<->Pet relationship: a foreign key that can be traversed in two directions.  With the database representation of the model you can't express the concept of a one-directional relationship.  This is a powerful differentiator for in-memory models, since it gives you much finer control over the semantics of your model than a database could ever provide.

So where does this relate to ORM?  Just like everything else in your application, Hibernate depends on your invariants being true in order to persist your model to the database.  If they're not true, Hibernate can't hope to do it's job correctly.  A huge number of "problems" that people starting out with Hibernate face have nothing to do with Hibernate itself, but rather are caused by an invalid in-memory domain model.  Coming from the world of procedural, SQL-based persistence, you don't necessarily have to worry about an in-memory domain model's integrity, which means that you can write what amount to buggy applications where the bugs never manifest themselves.

Bottom line is that if you're using an in-memory domain model, you simply must ensure the invariants of that model remain true.  More specifically, you must set both sides of every bi-directional relationship.  If you don't, you're just asking for punishment, both from your software tooling and from users/clients of your application.

<cfapplication name="ormtest1" />
<cfset companies = ormExecuteQuery('from Company') />
<cfinclude template="../app1/dsp_home.cfm" />

<cfset ormCloseSession() />

<cfapplication name="ormtest2" />
<cfset people = ormExecuteQuery('from Person') />
<cfinclude template="../app2/dsp_home.cfm" />

Here's the Application.cfc that this snippet runs under:

component {
 this.name = "ormtest3";
}

No ORM awareness at all.

The primary gotcha is that the other applications (ormtest1 and ormtest2) have to have been previously initialized (which you can do with a simple HTTP GET), but this allows you to mix multiple persistence contexts together (much like you can with normal Hibernate), and beat the stupid Application.cfc binding to some degree.  You still can only exist in a single context at any given moment, but you can switch back and forth any place you can close/reopen a session.

And for those of you who are thinking ahead, no, you can't manually manage your session objects instead of letting CF.  You can get a cross-application reference to the SessionFactory without much issue, and you can create a session, and you can even query for entities, but when you get to traversing lazy-loaded relationships it bombs out for some reason.  CF needs to have control over the active session or it doesn't work.  Rather sad, but at least running multi-persistence-context apps is possible, even if not concurrently.