Thread

I heard it from afar… “DEEP RELATIONSHIPS”  let’s meditate.

If you adhere to the conventions of DMZ db setup, and you eventually wrap yourself with that concept and the schema of your database requirements, you will find that “DR” is so so the answer to this scenario.
I caught this discussion on a whim, and will try to provide some insight if I can.  However, the old cliche of “the Manaul has your answer” applies here to save the day.

Yeah, DMZ provides a lot of magic, but with many deep relationships, there are still considerations and trade-offs, and as you noted, even with hand-crafted SQL it’s not entirely simple to take care of everything all in one query.

Good luck putting it all together.

Oh, I missed that you had a question there.

EDIT: Assuming I use your example to get my widgets:

$versions = new Widget_version();
$versions->include_related('widget')->get();
foreach ($versions as ...

What would be a good way to get the ratings (and eventually comments, descriptions, etc.) for that widget_version (they would be has_many relationships)?

You’d be stuck with running a get on each, since there’s not really any way to combine them, and they’d all be has_many.

$version->comment->get();
$version->rating->get();
...

Well, I guess there’s also the option of grabbing, say, all comments in one query and then relating them via PHP logic (easier if you have an in-table foreign key rather than a separate join table).  That would be a trade-off of more memory usage for fewer queries.  I would probably only go that route if pages are really sluggish though.

With a ton of relationships like that, at some point I’d probably start to ask myself if I need to store it this way.  That is, is the rating really part of the comment?  Or can more information be added to the Widget_version itself?  Do I only care about the aggregate rating (storing a 0-5 as a field of Widget_version, or grabbing the SUM() from the DB rather than each record).  That sort of thing.

Of course, not knowing anything about what you’re trying to do, I have to give you the benefit of the doubt, and it may just be that you’ll have to live with it and optimize in other ways (selecting only necessary fields, using get_iterated, creating good indexes in your DB, etc.).  As long as you’re not generating mammoth pages though (dozens of widgets with all their associated records, and all the queries that would entail), I think you’ll have reasonable performance.

Thanks a bunch!

AD:
Hello everyone.
I’ve just uploaded new version of HTML table extension.

Now it supports _iterated get’s, has better docs and i’ve made few other tweaks.

Check it out 😊

I’m having an issue with include_related. I saw someone had the same problem a while back, but I don’t think it was resolved. Here is basically what’s happening:

$stories->where_related_link('parent_id', 198)
        ->include_related('link', NULL, TRUE, TRUE)
        ->get();

On my local server (MAMP on my MacBook) this works just find and for each “story” I can access its associated “link.” As soon as this code was moved to the web host, it stopped working. In order to access the “link” I have to remove the “include_related” and use:

foreach ($stories as &$story) {
    $story->link->get();
}

MAMP is running PHP 5.2.10, and the web host is running 5.2.12. Both servers are running the same application, same version of CodeIgniter (1.7.2) and DMZ (1.7.0).

On my local server (MAMP on my MacBook) this works just find and for each “story” I can access its associated “link.” As soon as this code was moved to the web host, it stopped working.

Have you tried debugging any?  What queries are being generated?  Are they different, or the same?

Make sure all errors are being output to the browser.

Are you sure that your database is configured the same on both?  Do you have the Production Cache enabled?  (If so clear it, and disable it.  If it works, you can try re-enabling it.)

Delete all application files (especially models and libraries) from the server and re-upload them.

Since both versions of PHP are close, you should see if there are known problems with the updated version of PHP.  Maybe a php.ini configuration change or something similar.

I test on PHP 5.3.1 and 5.2.11.  I have never had any issues switching.  (Well, since I updated everything to work with 5.3.)

I probably won’t be able to provide any support for a while, but maybe these suggestions will help.

I’ve a basic understanding problem with $object->save();

I want do create a fake row in the object for a dropdown-field in a form like (—please select—). How can i manage this?

$object->select(‘id,title’)->get();

gets me all items. that is OK. Now i want to add one Item with the row (‘NULL’,’—please select—’) to the object. I don not want to save this row but use it for a ‘has one’-relation without ‘NOT NULL’.

Is there something like:

$object->add_row(‘id,title’,array(NULL,’—please select—’));

for an Object?

Thank you an sorry for my bad english.

@wandschrank
This really doesn’t have anything to do with save, so I’m confused.

If you want to add a—please select—row, you just add it to your HTML code.  If you really need this on the object itself (which, in my mind, is a hack), then you can manipulate the $object->all array, which is a simple array containing models.  You could array_shift a fake object into the array.

(But this really should be handled in the view.)

As far as saving, you’ll need to check the validity of the field manually in the controller.

On my local server (MAMP on my MacBook) this works just find and for each “story” I can access its associated “link.” As soon as this code was moved to the web host, it stopped working.

Have you tried debugging any?  What queries are being generated?  Are they different, or the same?

I work with Seth, and did some testing on this issue as well. Using this function:

$posts = new Post();
$posts->include_related('category', NULL, TRUE, TRUE)->get();
$posts->check_last_query();
echo '<hr>';
foreach ($posts as $p) {
    echo $p->category->title . '
';
}

I get this result locally:

SELECT `posts`.*, `categories`.`title` AS category_title, `categories`.`created` AS
    category_created, `categories`.`updated` AS category_updated
FROM (`posts`)
LEFT OUTER JOIN
    `categories` categories ON `categories`.`id` = `posts`.`category_id`
ORDER BY `posts`.`created` desc
--------
Events
Events
News
News
News

and this remotely:

SELECT `posts`.*, `categories`.`title` AS category_title, `categories`.`created` AS
    category_created, `categories`.`updated` AS category_updated
FROM (`posts`)
LEFT OUTER JOIN
    `categories` categories ON `categories`.`id` = `posts`.`category_id`
ORDER BY `posts`.`created` desc
--------

Another difference, if it’s relevant, is that locally PHP is running as ‘Apache 2.0 Handler’, and remotely its ‘CGI/FastCGI’. MySQL versions 5.1.37 (local) vs. 5.0.90 (remote).

—————-
EDIT: The issue is persistent with or without production cacheing.
EDIT: Same result if both systems are using the same DB config.

@bojack
The query is correct, at least as far as having the joined columns.

Have you tried running that query manually on the server?  Is it returning the correct results?

Try calling get_raw instead of get, and looking at the CodeIgniter query result directly, to make sure that the results are correct there.

Assuming the queries are returning the exact same results, try using include_related without instantiating, and see if that works.  If that works, then most likely something is happening on the server that is causing $posts->_instantiations to be unset or set to NULL.

Assuming the queries are returning the exact same results, try using include_related without instantiating, and see if that works.  If that works, then most likely something is happening on the server that is causing $posts->_instantiations to be unset or set to NULL.

Now we are getting somewhere! Running this on both server works:

$posts->include_related('category')->get();
foreach ($posts as $p) {
    echo $p->category_title . '
';
}

So it seems to be related to the instantiating.

->include_related('category', NULL, TRUE, TRUE)

@bojack
There’s only two places that DMZ clears the _instantiations array.  Either immediately after processing a normal get query (in the _process_query function, which is only used in get and query), or the _clear_after_query function, which is only used when calling get_raw or get_sql.

You could insert some debugging code into the _process_query and _to_object functions to output the results of the $_instantiations variable.

If the array is correctly configured (it’s a map of related_field => array(db_column => instantiated_field), then something is wrong with creating and assigning the related column.

It’s possible that the version of PHP you have on the server doesn’t like the assign-by-reference used for _get_without_auto_populating.  If you don’t use auto_populate (which I recommend you don’t), you could try changing line 5956 from this:

$c =& $item->_get_without_auto_populating($related_field);

to this:

$c = $item->{$related_field};

I’m not even 100% sure the assign-by-reference is necessary at this moment, but since I put it in there, I probably determined it was required.

how could I create my own field type for htmlform FOR my extension without using a helper?
just like:

function _input_text($object, $id, $value, $options)

And how can could I call _input_text insite my extension class?

Thank

@Alface
The HTMLForm extension is no longer supported or being updated.

Feel free to modify the extension directly.