Pomm 1.x code examples

Here are some examples to show how to ues Pomm. If you are still wondering how Pomm is different from classical ORM, you should read this first.

Retrieving data

This is just a simple example of how Pomm makes things simple. Imagine you have such structure in the database:

Note the array of varchars for the authors field. Let's fetch a single result and see how it looks like in PHP:

Here is the result:

The types are converted into their PHP equivalents. The authors field is an array of strings, timestamps are turned into a php DateTime instance. This will also work with almost all basic geometric types, interval, hstore, ltree and pg objects.

findWhere

Assumed you have a power_supply_transformer table in your database in the online schema, a PowerSupplyTransformer model class will be generated with the namespace "YourDb\Online". You can directly retrieve PowerSupplyTransformer instances from the database:

Query builder

Pomm comes with a simple where clause builder to chain logical statements. Every statement embed the optional values that will be escaped. All Postgresql's operators and functions can be used in the passed conditions. The IN ( ... ) is also available.

Modeling entities

With Pomm, it is possible to changing the projection operation (SELECT). By adding or removing select fields the according entities are filled with different values set. These fields will be accessed like any other 'existing' field but will not be saved by UPDATE. The following example shows how to strip password information and add age information to a Customer mapping:

It is possible to create as many field getters as wanted, only getSelectFields, getGroupByFields and getFields are used internally by Pomm's finders.

Custom queries

Map classes are the place to code the queries that define new finders and processes in the database. SQL queries take advantage of Pomm methods to retrieve structure information and let the programmers to focus on what the queries actually do. The following query shows an example of a simple join:

Splitting the queries from the clause part is often a good idea so same queries can be re-used with different conditions. If no condition is to be used, the example below can be followed:

Generating model files

With Pomm, the database is the reference. Model files are generated by introspecting your database schemas. Generated model classes will have their namespace set upon database schema name. The following script generate the model files in the /tmp/YourDb/YourSchema directory.

Composite types

Composite types are a way to represent complex data as objects in a relational database. By example, lot of data are tied to postal addresses in databases. If these addresses are not to be shared between records, they could be stacked in the same table as the entity they belong to: better performances, easier to retrieve.

As any other types, composite types converters must be registered to the database so Pomm knows how to handle them. The third argument is the FQCN of the type that will hold the data. If not provided, the converter will input & output arrays. Otherwise an instance of the given class will be used.

The type class is straight simple, it does not even need a constructor if it extends \Pomm\Type\Composite. It is preferred to use objects instead of arrays as they can come with getters and setters but **composite fields must be public** in this class.

This instance is then automatically injected into entities and can be accessed as any other objects: