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.
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.
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:
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.
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
It is possible to create as many field getters as wanted, only
getFields are used internally by Pomm's finders.
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
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: