#object-relational-mapping

The most basic description of metaprogramming is code that writes code.

Anytime you write a program that outputs code you are metaprogramming, and this is, actually, a lot more common than you might think if you're new to the concept.

Metaprogramming is useful when you realize that what you are doing could be parameterized if only you could pass the name of a function you want to call as a string. Or, to use terminology from a post by Vedant Agarwala, any time you realize that you need to use parts of your program as data.

From personal experience, metaprogramming is dead useful for Object-Relational Mapping (ORM). If you use metaprogramming in certain circumstances when you are dealing with code generated by an object relational mapper you won’t need to frequently hand write additional, remove, or alter code every time you add, change, or remove some object or attribute in your database.

Metaprogramming is also what’s used to generate ORM code in the first place.

In addition, if you have ever used any kind of templating engine, for example, to server-render HTML that’s then sent to a browser—that’s metaprogramming.

Actually, that’s what a compiler is too. You write code in a high level language and the compiler writes machine code.

The important thing to remember is that you never want to metaprogram as a replacement for writing DRY code. If you’re metaprogramming because you got tired of copying and pasting, you need to rethink your strategy.

Here are a few articles others have written on the subject:

Meta Programming — the most memorable code I’ve written

Behind the Scenes of the 'Has Many' Active Record Association

The Magic of Metaprogramming

The Java Persistence API is a core API that forms the basic building block of different implementations of this API which include Hibernate and OpenJPA. These technologies are not necessarily ground-breaking as they are simply the latest in a long line of database abstraction technologies for the platform. Database abstraction is, in my opinion, something that any software developer who works with a database should learn to understand and utilize. Regular SQL, in its various forms, is not particularly well suited to be used from within an object-oriented context, as database normalization, which is generally a desirable trait in a database's architecture, means that pulling in a set of data usually means having to pull from rows in numerous tables. Using regular SQL, this is usually done using join queries or by sprinkling database calls throughout the code, as needed, to pull in bits and pieces of a record-set, as the code needs them.

To a developer who has any architectural sense or security knowledge, it quickly becomes apparent why the method of using straight SQL calls becomes either inefficient, dangerous, or both. While the issue of security deserves its own attention, suffice it to say that the use of regular SQL, within an application that is taking user input, creates potential security risks of SQL injection attacks and that the headache needed to make sure that they are prevented, itself, should be reason enough not to use regular SQL calls within a web application. From an architectural perspective, having to write extra code that converts results from SQL into an object-oriented data structure also creates headaches and takes away time from actually building the parts of the application that are specific to the business goals.

It is likely that if a team of developers begins trying to use regular SQL within an application, while addressing the issues above, that they would most likely begin building a layer of an application that would be attempting to resemble features already available within the Java Persistence API. Therefore, rather than re-invent the wheel, the decision to use the Java API should come naturally. JPA provides a simple, intuitive way to interact with a SQL database without having to code to the specific database, so that, for example, an application that starts out using MySQL could easily be changed to use PostgreSQL with only minor changes to configuration files. 

JPA allows database tables to be mapped to Java classes, with annotations being offered that help streamline the process. Rather than forcing a developer to concoct long-winded join queries, JPA essentially does this for you. All the developer has to do is define relationships, using annotations, within the table Java classes and you have the power of full data-sets at your fingertips. For example, you simply retrieve an object representing an entry from one database table, based on parameters passed in, and then you are able to call getter methods, where you would normally have foreign-key fields, to pull in the an actual object, or collection of objects, that are associated with the initial entry. After getting used to this, it can be hard to imagine ever going back to using straight SQL.

Beyond what is mentioned above, JPA has a number of useful features that are too complex to get into here in detail, including caching of queries and lazy initialization. Both of these features are meant to enable configuration to save on resource usage. Caching enables saving on calls to the database which reduces strain placed on the DB and increases application performance. Lazy initialization also saves on unnecessary queries, while preserving application RAM usage, by only retrieving an associated data-set object when it is called from within the application code.