Thread

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.

Requirements

1. PHP v.5.3.x
2. CodeIgniter v.2.x.x

Features

All you know from previous version, plus :
1. Supported databases including PDO, if you keep sync with CI repo.
2. Cascade delete.
3. Namespace and PHP5 autoloader.
4. Support composite keys (for key that define relationship).
5. Included phpunit test suite.

Teaser

// Finder
$users = Model\User::all();
$some_user = Model\User::limit(10)->find_by_active(1);
$some_user_kid = Model\User::find(1)->kid()->name;

// CRUD
$new_user = Model\User::create($_POST);
$new_user->save();

// Eager Load
$users = Model\User::with('wife','kid')->all();
$some_user = Model\User::with('wife')->delete();

// Extension
$user_form = Model\User::html()->find(1)->form('user/edit'); // Generate form edit
$user_table = Model\User::html()->all()->table(); // Generate table

For download or recent update, look at Gas ORM @ GitHub. This library also available at Sparks. For guide and example go to Home of Gas ORM.

Cheers.

Note :
1. Im no longer add new feature on old version(1.x), but if you have any issue or bug report on that version, nudge me on this thread.

Great!

I never resolved my issues with the previous Gas ORM version. I will download and switch to this since I am not invested that much yet. Looks great!

What issue you couldn’t resolved on previous version?

With Pivot tables, why is the pivot model now located in a sub folder?
What is the reason that Jobs_User is in Jobs/User.php? Is it based on the table name, or could I just as easily make User/jobs.php?
Does User/jobs.php need created as well?

I read over the new documentation, and am working now to upgrade. Everything looks create so far. Thank you for adding the section on Pivot tables to the doc! This was a area I was shooting in the dark with from the previous version.

Didn’t see your response. Sorry.

The relationships were fine and recorded correctly, though when retrieving the data, it was problematic.

I already wiped the old models, so I don’t have everything to post from. But the short version is this.

Skills table had several pivots to Professions, Sets, Types and Pets.
All relationships seemed set up correctly, no spelling errors that I could find.
When getting a result from Skills, I could print out any relations for Sets, Types and Pets, but nothing would show for Professions.

If I used With() in my Query, I could sometimes access the relation. For example, if I used With(‘Types’) I could access the Skills->Types object. If I used With(‘Sets’), sets would all of a sudden not be returned, even though it was returned and worked fine with Types and without the With method at all.

I was never able to fix the issues, and I have started from scratch again.

I don’t fully understand the intention of With, from the doc (older version of Gas ORM) it sounded like it was designed to only return the relations I needed, instead of everything. When I specified a relation that I needed, it would always still return everything, unless it made it bug out.

Note that the only time I ever received a error was when I used With(‘Professions’) and then the error was about wrong type of data in a Foreach.

When With() screwed up, or when Professions was not included, they would result in a empty array.

I deleted old models, old libraries, old extensions. Uploaded all new files.

Getting a Error Message…

Parse error: syntax error, unexpected T_STATIC in /mounted-storage/home71b/sub007/sc41106-WCWU/guildwars/application/libraries/gas.php on line 73

Which is:

{
  if (static::$init == FALSE)
  {

Which is set above (line 63)-

protected static $init = FALSE;

Not sure what is going on that this would happen…

*UPDATE* - Apparently the shared host I am on is only Version 5.2.42…
Assuming this is a PHP 5.3+ feature?

@Khrome83, yes. Line you refer, was a late static binding, which available on PHP 5.3+. Try to contact your hosting support, to uprade your PHP version.

Regarding your question :

With Pivot tables, why is the pivot model now located in a sub folder?
What is the reason that Jobs_User is in Jobs/User.php? Is it based on the table name, or could I just as easily make User/jobs.php?
Does User/jobs.php need created as well?

It located in a subfolder, as a part of namespace convention. So namespace also contain information, that will be used by autoloader to find the model(s) file.

// I try to make the convention as close as possible with psr-0 rule 
Model\User     ====assumed located in===> models/user.php
Model\Job      ====assumed located in===> models/job.php
Model\Job\User ====assumed located in===> models/job/user.php

You can have job_user in user/job.php but you will need to set $table property if table name and model name are not in the Gas convention.

Hey toopay, I’m getting this error when generating my models:

A PHP Error was encountered
Severity: Notice
Message: Undefined index: migration_table
Filename: classes/core.php
Line Number: 2199

The line is this:

if($table != self::$migration['migration_table'])

Also, after this warning, it quits on this error:

An Error Was Encountered
Gas ORM cannot create a model(s) file at: ../application/models\fields\of\study.php

I’m guessing it has something to do with the ‘fields’ part of my table name which is fields_of_study. Is there a way to fix this? And does it have to go into a subdirectory? I don’t really need that.

I can confirm the same error -

A PHP Error was encountered

Severity: Notice

Message: Undefined index: migration_table

Filename: classes/core.php

Line Number: 2198

Though all of my models were still created. I had my tables already setup in the database, as well as a migration file uploaded to the server. I verified there creation just fine. They even created the sub directory for pivot tables just fine as well.

@DerLola & Khrome83,

What version of CI you guys used? Do they have migration.php within application/config folder? If so, could you find a line contain :

/*
|--------------------------------------------------------------------------
| Migrations table
|--------------------------------------------------------------------------
|
| This is the name of the table that will store the current migrations state.
| When migrations runs it will store in a database table which migration
| level the system is at. It then compares the migration level in the this
| table to the $config['migration_version'] if they are not the same it
| will migrate up. This must be set.
|
*/
$config['migration_table'] = 'migrations';

Line you guys pointed, is to avoid creating model for migration table, since its not part of your application.

Also, after this warning, it quits on this error:

An Error Was Encountered
Gas ORM cannot create a model(s) file at: ../application/models\fields\of\study.php

I’m guessing it has something to do with the ‘fields’ part of my table name which is fields_of_study. Is there a way to fix this? And does it have to go into a subdirectory? I don’t really need that.

Well, it assume all of your entities is in a single word. user to hold user entity, book for books entity and so on. And it assume all table with _ (underscore) as a pivot table, which associate entity, eg : job_user to associate user with job and so on. I encourage you to use this convention, for your convenience.

If for somehow reason(s), you cant follow those convention, you always still could create your model based by your own convention, manually 😊

Migrations are stored in migrations.

I am using version 2.1.0.

In my migration.php in config folder, I do not have the option you have posted. This might be a newer feature than 2.1.0.

This is the entirety of my migration.php file -

<?php defined('BASEPATH') OR exit('No direct script access allowed');
/*
|--------------------------------------------------------------------------
| Enable/Disable Migrations
|--------------------------------------------------------------------------
|
| Migrations are disabled by default but should be enabled 
| whenever you intend to do a schema migration.
|
*/
$config['migration_enabled'] = TRUE;


/*
|--------------------------------------------------------------------------
| Migrations version
|--------------------------------------------------------------------------
|
| This is used to set migration version that the file system should be on.
| If you run $this->migration->latest() this is the version that schema will
| be upgraded / downgraded to.
|
*/
$config['migration_version'] = 1;


/*
|--------------------------------------------------------------------------
| Migrations Path
|--------------------------------------------------------------------------
|
| Path to your migrations folder.
| Typically, it will be within your application path.
| Also, writing permission is required within the migrations path.
|
*/
$config['migration_path'] = APPPATH . 'migrations/';


/* End of file migration.php */
/* Location: ./application/config/migration.php */

Ok, thanks for the confirmation. I guess i tend to keep the gas repo sync-in with the latest EllisLab repo. But i’ve just adding something to avoid those warning, both in download page and in repo.

Instead re-download, you two can just replace

if ($table != self::$migration['migration_table'])

into

if (empty(self::$migration['migration_table']) OR $table != self::$migration['migration_table'])

This way, the autogenerator will works both for 2.1 and 2.1++ without throwing some warning.

I had the chance to test it yesterday and v2.0 looks really impressive! 😊

Great job done as usual.

Stefano

Thanks for the fix toopay. The assumption that an _ always indicates a pivot table is not true in this case. I’ll generate the models manually. Ah well, having them automatically generated was a luxury anyway 😊.

Now I’m running into this other thing. When I load the Gas ORM Spark, my base_url and site_url are emptied. So

public function index()
{
 $this->load->helper('url');

 echo 'base url: ' . base_url() . '<br>';
 $this->load->spark('gas/2.0.0');
 echo 'base url: ' . base_url() . '<br>';
}

base url: <a href="http://local.mysite.com/">http://local.mysite.com/</a>
base url:

Also, I really appreciate how you keep improving the lib. Keep up the good work!

I am still working on converting over to Gas ORM 2.0.

I came across a issue that I was hoping to get more information on. In the old version of gas, when Auto Generating models, the fields support ENUM, while the new version does not. Do I need to convert these myself to ENUM of type string.

Old Auto Generated Fields

'id' => Gas::field('auto[16]', array(), ''),

   'name' => Gas::field('char[64]', array('required'), ''),

   'description' => Gas::field('string', array(), ''),

   'recast' => Gas::field('int[3]', array(), ''),

   'activation_time' => Gas::field('int[2]', array(), ''),

   'activation_type' => Gas::field('string', array(), 'ENUM'),

   'skill_points' => Gas::field('int[3]', array(), ''),

   'slot' => Gas::field('string', array(), 'ENUM'),

   'chain' => Gas::field('string', array(), 'ENUM'),

   'created' => Gas::field('datetime', array(), 'TIMESTAMP'),

   'updated' => Gas::field('datetime', array(), 'TIMESTAMP'),

New Generated Fields

'id' => ORM::field('auto[16]'),
   'name' => ORM::field('char[64]'),
   'description' => ORM::field('string'),
   'recast' => ORM::field('auto[3]'),
   'activation_time' => ORM::field('auto[2]'),
   'activation_type' => ORM::field('string'),
   'skill_points' => ORM::field('auto[3]'),
   'slot' => ORM::field('string'),
   'chain' => ORM::field('string'),
   'created' => ORM::field('datetime'),
   'updated' => ORM::field('datetime'),

I am assuming in the case of Slot, I would convert this too -

'slot' => ORM:: field('string', array(), 'ENUM'),

The other thing to note, is that for ‘recast’, ‘skill_points’, ‘activation_time’ it has them set to AUTO as opposed to INT, even tough they are in in DB without the Auto Increment flag associated with them.

Additionally, before Gas ORM 2.0 I was using -

private $_types;

 function set_types($types) {
  $this->_types = array('types_id' => $types);
  return $this;
 }

function _after_save() {

  if ($this->empty) {

   // Record ID
   $id = $this->last_id();

   // _types
   if(is_array($this->_types)){
    $this->_types['skills_id'] = $id;
    $this->db()->insert('skills_types', $this->_types);
   }
        

  }

 }

I am guessing most of this will still work, but maybe I need to convert the insertion to -

if(is_array($this->_types)){
    $nr = new Model\Skills\Types();
    $nr->skills_id = $id;
    $nr->types_id = _sets['types_id'];
    $nr->save();    
   }

or

if(is_array($this->_types)){
    $this->_types['skill_id'] = $id;
    Model\Skills\Types::make($this->_types)->save(TRUE);
   }

Is there a better way when inserting data with a pivot table?

In this situation I have a one-to-many relationship with skills = types.

So I am updating skills and want to specify the type for it, which goes through the pivot table skills_types, is there a better way?