[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
@leviathan28

Well, I one-upped that. I did go ahead and fix the result of count() to force the result to an int.

But I've also implemented a new feature I've been wanting, and that is validation-like rules that are processed immediately after loading an item from the database.

The two main uses I see for it are:
1) Forcing integer values to be ints. Currently the code handles the 'id' column, and all in-table foreign keys, like 'user_id'.

2) Converting dates and the like. You can now easily call strtotime on a field after loading it from a database to force it to be a timestamp.

But I'm sure there will be other uses for it as time goes on.

Once I get time to write up docs for this and a few other changes, I might push it out live.

[eluser]sethbaur[/eluser]
Ok I'm having another problem related to include_related. Here is the same code from before:

Code:

$updates = new Update();
$updates->order_by('created', 'DESC')
  ->include_related('uri', array('uri_string'))
  ->include_related('section', array('title'))
  ->get($per_page);

Now, in the config I set "auto_populate_has_one" to TRUE. When I do this, whichever is the first "include_related" fails, but the second works. So in the above code, including "section" works, but not "uri." If I reverse the statements, "uri" works, but "section" does not.

So I get an error message that either looks like this:

Code:

A PHP ERROR WAS ENCOUNTERED
Severity: Notice

Message: Undefined variable: uri_uri_string

Filename: updates/preview.php

Line Number: 5

or this:

Code:

A PHP ERROR WAS ENCOUNTERED
Severity: Notice

Message: Undefined variable: section_title

Filename: updates/preview.php

Line Number: 2

Any ideas why this wouldn't work?

[eluser]PoetaWD[/eluser]
hello,

This is not a question reguarding DMZ... sorry to post it here... but you are my best friends over the internet ! the people who teach me how to program !



Well..

I am making a website and in its front page I want to put the last 3 articles.

The problem is that I do not want to put the full content of the article, I just want to put the first 100 characters of its content !

How to do that in PHP ?

controller:

Code:

$a = new Article();
        
        $a->order_by('id', "DESC")->get(3);
        
        $data['articles'] = $a->all;

view:

Code:

foreach($articles as $article) {

echo $article->created;

echo $article->title;

echo $article->content;

}

Is there a way to make the "echo $article->content" only show 100 characters ?

Thank you !

[eluser]jpi[/eluser]
http://ellislab.com/codeigniter/user-gui...elper.html

$this->load->helper('text');
echo character_limiter($article->content, 100);

A good start in CI is to read the userguide... twice ... (just kidding )

Edit : it's true for PHP Guide too here

[eluser]OverZealous[/eluser]
[quote author="sethbaur" date="1250277101"]Now, in the config I set "auto_populate_has_one" to TRUE. When I do this, whichever is the first "include_related" fails, but the second works.[/quote]

I was looking this over, and I know what's happening. It makes sense now.

Basically, there is only one ActiveRecord object, which means you can only set up and run one query at a time.

However, auto_popupate_* can magically get run at any time. And it automatically loads the related item by using AR. So, the code in your example gets trampled when the auto populate kicks in.

There are several solutions, the first two you can use right now:

1) Don't use auto_populate (at all). Not really a great recommendation, because it can be a great feature for $has_one relationships.

2) Make sure you always access related items before calling include_related:

Code:

$updates = new Update();
$updates->uri; // ensures that it is preloaded
$updates->section; // ensures that it is preloaded
$updates->order_by('created', 'DESC')
  ->include_related('uri', array('uri_string'))
  ->include_related('section', array('title'))
  ->get($per_page);

This is a good, short-term workaround until I get the next release out there with a more permanent fix.

3) I can make changes to DMZ to not use auto_populate when accessed while using a query method. The drawback here is it can leave your object unloaded, and it will then never get autoloaded. It also requires a little work on my part, to ensure that the object never gets autoloaded while setting up a query. And it only would help from within the object's query methods, not if the object is accessed independently.

4) When autoloading an object, deeply clone the DB object, so it has it's own, independent copy of the database object. I have already had to do this for one of my functions. This could be a performance issue, because as of PHP 5.2.10, this is the only way I've found to ensure that the DB object is deeply cloned (and the ActiveRecord arrays are not shared):

Code:

$related->db = unserialize(serialize($related->db));

It's less than ideal. But it does prevent the related object's query from trampling over the main query.

5) I could "back up" the current object's query when auto loading, and then "restore" it afterwards. And now, the more I think about it, this seems like the correct one to try. It has the lowest performance penalty (only once per auto-load).

I did already add one minor benefit: the auto_load code will no longer run on objects that do not exist(). So, in your example, it would not have run, because it was a new Update.

Any feedback would be greatly appreciated!

[eluser]North2Alaska[/eluser]
I'm just beginning to convert an existing project to use DMZ. I've not got as far as any actual code yet, I'm just building the database; renaming columns, adding ID columns, adding create and change dates and renaming and/or adding join tables.

But I've run into a stumper. I have tables named AREAS, USERS and PROFILES. AREAS and USERS are a many to many so I create the AREAS_USERS table. No problem. But now PROFILES. Each user will have one profile per area. So, I have been using the AREAS_USERS for this purpose and keeping a AREA_ID and USER_ID in the PROFILES table. But I believe this will break the naming conventions.

So, before I get too far, I thought I would just ask how is the best way to handle this relationship? I could have an AREAS_PROFILES table but that doesn't take into consideration users. Do I create a AREAS_PROFILES_USERS table? Or maybe an AREA_USERS_PROFILES table as the AREA_USERS it what I'm joining to.

As I'm writing this, I'm seeing that I could use just a has_many from the AREAS_USERS table to the PROFILES table. And a has_one from the PROFILES table to the AREAS_USERS table.

Just a little kick in the right direction would be appreciated.

--
Jesse

[eluser]OverZealous[/eluser]
[quote author="North2Alaska" date="1250661891"]So, before I get too far, I thought I would just ask how is the best way to handle this relationship?[/quote]

I just answered this on the previous page. ;-)

[eluser]North2Alaska[/eluser]
[quote author="OverZealous" date="1250662097"]
I just answered this on the previous page. ;-)[/quote]

OverZealous is so smart, he answers our questions before we can even ask them. :-P

I will study your examples and the attempt some code. Thanks Phil.

--
Jesse

[eluser]mcnux[/eluser]
Quiet week, lucky you! Then I came back :-)

I'm having an issue with queries which include related tables but also use the standard where() method to query the originating model/table. The issue being no table is added to the column from the where clause and therefore the query doesn't know which table's id column to query, resulting in the error "column id is ambiguous" Here's an example of what I'm trying:

Code:

$jobs = new Job();
$jobs->where_in('id',$idArray)->include_related('location','name')->get();

// results in query:
SELECT
  jobs.*,
  locations.name AS location_name
FROM
  jobs
  LEFT OUTER JOIN locations ON jobs.location_id = locations.id
WHERE
  id in (1,2,3) // MySQL says who's id?

I'd rather not have to change my where_in to where_in('jobs.id',$idArray) as this is directly referencing the table name when I want to construct the query using model names only and let the datamapper do it's job of mapping to the correct table.

Please advise.

[eluser]OverZealous[/eluser]
@mcnux
I think this is caused by a bug fixed in the current (unreleased) version of DMZ. Try turning off $auto_populate_has_one, OR, rewrite your code to look like this (recommended for the time being):

Code:

$jobs = new Job();
$jobs->location; // triggers $auto_populate_has_one
$jobs->where_in('id',$idArray)->include_related('location','name')->get();

You will be able to remove this change after the next release. I do not have a date in mind yet, however.