Thread

ok.. works!
The problem was the validation!

😊

Hey, i love your library and the whole concept of DataMapper.

Only problem I’m having so far is calling the models within my libraries.

In my libraries i call the codeigniter instance:

class Library {
     
   var $ci;

   function __construct()
   {
       $this->ci =& get_instance();
   }
   
   function my_function($user_id)
   {
       $user = new User();
       
       $user->where('id', $user_id)->get();
   }

}

But when i call my User model, i get the error message: Trying to get property of non-object.

Does anyone know the correct way to call models withing libraries? Or is this not possible..

Datamapper doesn’t need the codeigniter instance, and there is nothing wrong with this piece of code.

You don’t have an other class called ‘User’ by any chance? Do a var_dump($user) before the where() call to see what object you got.

Hello!

I am using Codeigniter 2.0.3 with DataMapper ORM 1.6.0. Integration DataMapper in CI has been implemented successfully and everything works fine, except password encryption.

My question and sample code is on StackOverflow.com.

User successfully stored in the database but with original password not encrypted.

Any solutions?

Regards, Mario

Datamapper 1.6.0 is ancient, and no longer supported. I’m not even sure that functionality existed back then…

So what should I do now? Download other version? Thanks..

At the moment you’re a bit stuck, as the latest Datamapper version, 1.8.1., doesn’t work with CI 2.0.3.

The reactor team is busy with an overhaul of the CI core classes, which causes everything to break that needs to access CI’s internals, including Datamapper.

To get it to work you’ll have to patch CI’s AR database class, and change all ‘protected’ methods and properties back to ‘public’.

I want to get just one row on my table, and I’m doing like that:

$row = $user->where('name', 'username')->get();
print_r($row);

but this query giving me 4000 line lenght array, why so many information in this basic query?

my table name, configs, database passwords, models name, language arrays…....

isn’t this bad for memory and performance?

I’m just want to get ID, name, email to one varible.

Datamapper isn’t a query builder, it’s an ORM.

You therefore are not getting an array back (or a standard data object), you are getting a Datamapper object back.

I assume you’re coming to this conclusion because you dumped the variable. Like with CI itself (ever tried to dump the CI instance?), most of what is in the object is linked by reference, and doesn’t take up any space, apart from a few bytes for the resource reference.

The only data actually in the object is information about the table (like name, columns, relations, etc), and the data of the first record returned by the query. If the query returned more records, they are also objects, linked to the first so you can iterate over them.

Having said that, off course with every layer of abstraction you add, you also add memory usage and lose some performance. Hardcoding the data is more efficient then using native PHP mysql functions, which are more efficient then using CI’s DB classes, which are more efficient that using CI’s AR classes, which are more efficient than using an ORM.

But by adding abstraction, you also add simplicity, a DRY approach, and quick development. You also add easier and shorter maintenance cycles.

Wether or not you should use an ORM is entirely up to you, and your specific situation.

If you code for free, if you host 5 buck-a-month websites with a million visitors, then maybe an ORM is not for you, and you should code as low-level as possible to squeeze every clock-tick out of your code.

If on the other hand you’re writing corporate applications, if you work in a team, if your hours are worth 75$, then an ORM is definately something for you. The money your client or employer will save in shorter development and maintenance cycles will more than outweigh the money needed for some extra CPU power…

I understand and I know, but this does not answer my question.

Then I suggest you read it again.

Your direct question was ‘is it bad for memory and performance’. And they answer above was ‘not bad, but it will affect both’.

$row = $user->where('name', 'username')->get();

doesn’t run a query and returns an array of values. If you want that, use a standard CI query.

It returns an instance of a model class, which like a CI model, will include all kinds of information needed for the class to operate. And which, since most of it is linked by reference, doesn’t take up any extra memory. Altough when you var_dump() it, it will return an enormous amount of data.

ORM’s are for people that don’t want to use CI’s singleton models and deal with array’s, but want a full object oriented aproach to dealing with data.

OK, I change my question; How can I get a row with ORM?

Exactly like you did it in your first question.

// create a model instance
$record = new Record();

// get some records
$record->where('field', 'value')->get();

// loop over them
foreach ($record as $r)
{
    // echo a column from the record
    echo $r->field;

    // get child records
    $r->child->get();

    // and echo a field from the first child
    echo $r->child->field;

    // store the record in an array
    $array[] = $r->to_array(); // requires the array extension to be loaded
}

With on ORM you should stop thinking in terms of rows and arrays. A row is an object, and has links to other objects (or more of the same).

I suggest you take some time to go through the documentation. It’s quite extensive, and contains lots of examples. See the link in my signature.

You will have to get your head around the difference between a CI model and an ORM model.

In case of CI, the Model class is a singleton (there is only one instance) which is accessed via $this->Model, and from a technical point of view behaves just like a library. It contains only reusable logic, no data, which is returned to your controllers for further processing, leading to ‘fat’ controllers.

With an ORM, every instance of data (usually a table row) is a Model object, which encapsulates both the data and the logic as a self-contained entity. All operations on the data, from custom selections, pre- and post processing, to validation, happens inside the model.

The upside of this is that you no longer have ‘fat’ controllers, they are now doing what they should, which is control the flow from request to output, calling the models and loading the views. The upside is also that no matter from which controller you access your data, access is always consistent, as the model will take care of that for you.

Altough Datamapper allows you to keep creating ‘fat’ controllers using code like in the example above (and to be honest, most users use it like that), the idea is that you add custom methods to your Datamapper models that contain the data handling logic.

So in the above example, create a method in your model:

// get an array of id's and fields based on field selection
public function field_to_array($field)
{
    $this->where('field', $field)->get();

    $result = array();

    foreach($this->all as $record)
    {
        $result[$record->id] = array(
            'id' => $record->id,
            'field' => $record->field,
        );
    }

    return $result;
}

and then in your controller just use

$record = new Record();
$array = $record->field_to_array('value');

Wanwizard, i like the idea of fat models, and i was wondering if extending DataMapper models, when needed, would be an option. Would the next example be problematic in any way for DataMapper model handling?

For example a User model for the front end login etc. and a more extended version with methods for deleting, adding and modifying users. This way you can have an even more leaner model for the front-end and a more extended version for administration purposes or more elaborate data fetching.

// Basic user model
class User extends DataMapper {
  // validation
  // constructor
  // login_method
  // get_user
}

// Extended user model, for admin etc.
class User_extended extends User {
  // call parent::constructor
  // add_user
  // delete_user
  // (can even override or extend the login_method)
  // etc.
}