A lighweight and easy-to-use ORM for CodeIgniter. Gas was built specifically for CodeIgniter app. It uses standard CI DB packages, also take anvantages of its validator class. Gas provide methods that will map your database table and its relation, into accesible object.
1. Supported databases : cubrid, mssql, mysql, oci8, odbc, postgre, sqlite, sqlsrv.
2. Support multiple database connection.
3. Support modular models directories and sub-models directories.
4. Multiple relationship (has_one, has_many, belongs_to, has_and_belongs_to) with custom relationship setting (through, foreign_key, foreign_table, self).
5. Auto-create models from database tables and vice versa, and auto-synchronize models-tables by creating migrations file.
6 Per-request caching.
7. Self-referential and adjacency column/data (hierarchical data).
8. Eager Loading.
9. Various finder method (can chained with most of CI AR syntax) and aggregates.
10. Validation and auto-mapping input collection, with minimal setup.
11. Hooks points, to control over your model.
12. Extensions, to share your common function/library/helper/plugin across your model instances.
13. Transaction and other CI AR goodness.
14. Command Line Interface.
1. Support for tree traversal data.
More useful features.
NOTE : latest version is v.1.4.3 (also compatible with the latest CI 2.1.0), if you using < v.1.3.0, please update. Also note that Auto-create models from tables and vice versa require CI v.2.1.x
Two weeks and two new CI orms….what is the world coming to?
You guys should all contribute together.
JonoB, i dont know what you mean or refer, by stating “two new CI ORMS”. Actually, in CI world, there was already great ORM, which is DataMapper. If i should choose, between Doctrine, PHP AR or that (DataMapper), i will actually choose DataMapper. Because it utilize all CI goodness, rather than bring feoreign packages (a huge one) into your codebase. So, by using semi-native ORM like this(DataMapper, or Gas), you remove yourself from the duplication carried by foreign code/packages from your codebase, such as Doctrine or PHP AR, which each have their own database and validator package(s).
But for some reasons, especially easy-to-use part, i found DataMapper slightly “obsolete” compared with recent popular ORM, in terms how they utilize and make user easier to implement their ORM methods. Thats why for my recent CI app, i create my own. Feel free to submit any issue/bugs you found, and thats why i publish this library for.
Because some user which test it last night, send me a message that they have an issue when running in PHP < 5.3, and i found it because in my initial version, i have some line that passing…
directly as a function’s parameter, and that will fail in PHP under 5.3, so i know whats wrong, and my recent app avoid future potential bugs early.
So when i wrote this (and other library i have in my signature), i have a business case
@Stefano, thanks for doing some research/test on it, i appreciate that. I just merge several commits, beside fixes some issue which reported by some user, iam also adding a controller contain unit-testing procedure to performing test : evaluate all available implementation to determine if it is producing the correct data type and result, feel free to submit any issue(s) if you still found any.
@Stefano G :
You may notice that because you are try to fetch a child object from a user resources which has one-to-many or many-to-many relationship, you should expect to accept an array (just like if you go with PHP AR, for example). So actually, if you do
For license compatibility reasons, i ended up change all my library license, including Gas ORM from GPL to compatible license. By latest commit, Gas ORM is now also compatibility with PHP v.5.2.x, since some issues reporting by user based by previous commit (same version) under PHP 5.2, which apparently caused by Scope Resolution Operator.
Oh btw, i’m start adding language files, so if your language isn’t there, dont hesitate to add/pull request your language on it.
@ardinotow, In earlier version, when we try to fetch record(s) from a table using a finder with Gas ORM, either we try to fetch a set of records or just a single record which didnt exist, Gas will return an instance with empty record, so we could use ‘has_result’ method. This could be a problems, since if the records exist, find() will return an object while all() will return a set/array of object. To resolve this non uniformal behaviour, i had encourage people to use empty(), because Gas will return FALSE(for single record method) or empty array(for all(), or any finder which expect more than one records) if queries return an empty response.
So, you could do something like this instead:
$user = Gas::factory('users_data')->find(2);
$profile = empty($user) ? 'User not found.' : $user->user_profiles;