The little things...

It is always the little things that make such a difference...

We, at synapticloop, try our best to reduce those little, tiny, small annoyances that irk you about other frameworks. We code __A LOT__ so all of those little things pretty soon add up to a major grievance. Where we can, we try to catch them up front, or at least flag them as errors to you.

As we carry on our journey through our code, if there is anything that irks us, even a little bit, that we could catch, we update the code and push out a new version. Here are some small examples:

  • FATAL validation errors - we were tired of back-scrolling through the lines of text to figure out where the fatal validation occurred - so we print them out at the bottom as well
  • .h2zero file expansion - we found that the h2zero definition file just got too long and too complex, so we added in the import command for tables. Allowing us to split up each of the files per table.

Regeneration changes nothing! (apart from what has actually changed)

On quite a frequent basis, we delete out h2zero generated code - we always namespace our generated code clear of everything else. We can then re-generate the code, and the only thing that has changed will show up. If nothing has changed, then out source code repository won't flag a thing. In fact, you could just ignore the generated source code and generate in at build time.

No Exceptions to the rule

We generally use the *Silent methods on all of our calls - and then test the return value. This does have one down side though - if there is a SQLException in what has been generated then this will also be hidden - luckily we run through our unit tests to ensure that everything is working as it should...

Walking the tree

Let's say you have a pet which has a foreign key relationship to a user (i.e. you may have multiple pets for each user). To get the the user from the pet, you can justcall pet.getUser() and we will automatically load the user from the database for you.

You have to have standards

We use a standard naming convention for all of our finder / counter / updater / deleter / question methods, that way we know what each method does explicitly in the database.

Bound to be good

We use a static final String BINDER for all of our model objects and then reference them from the other parts of the generated code. This way we always know if the underlying database changes (and a table is renamed or deleted) that the 'dead' code is then flagged by the compiler.

Logging

We aren't quite sure what your logging framework is going to be (we prefer log4j for historical reasons), so we leverage slf4j,so that you can use whatever bridge you would like to your logging framework.