First of all thanks for the wonderful video’s, I’m learning a lot!

But I have a question:

On my index, I want to display the contacttype besides the name. Now I’m using a foreach on standard info. How do I mix these together to display the names from both the tables?

obviously the former approach will be slower since you’re essentially making a separate transaction for each call and you’re generating many more queries. This is where a proper ORM helps a lot since it will (or should) cache repeat queries that rely on a particular relation. Handling the joins yourself can be tedious since it pulls you outside of the object model and into a db relational model.

what are your ideas with regard to Zend_Db_Table and speed. I’m currently doing some research on one to many and many to many relations with Zend_Db_Table.

Using examples like yours or the ones given in the Zend Framework Reference guide, I see a dramatic performace with regard to speed.

If I for instance have tables

A
B
and AB

where AB defines the many to many relationship between A and B (two identifier colums in AB, namely Aid and Bid, both function as joined primary key, both in Foreign Keys to the respective tables)

Now I’ve got the Model structure set up as supposed and everything works fine. But then I do

$result = A->fetchAll()
foreach($result as $row){
$details = $row->findManyToManyRowset(‘B’, ‘AB’);
foreach($details as $detail){
…echo something…
}
}

If I do this for let’s say 150 parentrows with an average of 3 child rows this operation takes a whopping 13 seconds. If I do a join statement in parent’s foreach loop, if finishes in 1-2 seconds…

Relations with Zend_Db_Table are SLOW

Everything works like a charm – right up to the end. When I click on the ContactType (ie: Business, Other or Personal), it always defaults to the first one “Business”.

I’ve check all the code (I think) as well as the database and I just can’t see the problem.

Anybody else come across this?

I haven’t touched Zend_Db_Table in 1.9, however I think I read something about how the model_ prefix isn’t required. I believe someone posted about this on the Zendcasts forum a couple weeks back. Hopefully, all this will be sorted once PHP 5.3 is adopted and we have proper namespacing.

I got an issue at the end of this tutorial and i think this is something about the new framework 1.9. In fact from the beginning of this tutorial i have to name my models “Default_Model_ContactTypesTable” (which is really annoying) to make things work properly.
And when i use findDependentRowset(‘UsersTable’) i’ve got an error that i didn’t manage to solve : Message: File “UsersTable.php” does not exist or class “UsersTable” was not found in the file

Of course UsersTable.php exist :p

Any idea ?

Thank you.

Seb.

telling you up front: great tutorial!
Besides your introduction of the service layer, you mention the use of domain driven principles like repositories and unit of work. Is it possible to do a tutorial where those principles (like factories, repositories, unit of work, etc..) are exposed?

Thanks.

You’re absolutely correct! This video was done with the intent of showing the Zend_Db_Table functionality, unfortunately I didn’t get to really build on the service layer concept due to time. In production, I would probably keep the responsibility for OR-mapping in the models. The service layer is really just a primitive implementation of the Repository concept. Ideally, if this was a larger application, I would suggest using a Repository with a UnitOfWork that would isolate transactions and object creation / persistence. The upper tier would only be concerned with querying the Repository for objects and then passing them back.

I’m wondering why you are using current() and findDependentRowset()methods directly from action controller.
In that case you’re losing the benefit of the Service Layer which is to uncouple application logic and persistence (Zend_Db).
There, you’re just using Zend_Db_Table methods from controller.
Or maybe it was to just get to the point with findDependentRowset and you decided to not specify this detail (but still important). If that’s it, i’m sorry for disturbing

Cya,

Benjamin.

I thought it will be some useful trick at beginning.

I would double check the code sample:

http://code.google.com/p/zendcasts/source/browse/trunk/ep20-one-to-many-with-zend-db/application/default/models/ContactTypesTable.php

and

http://code.google.com/p/zendcasts/source/browse/trunk/ep20-one-to-many-with-zend-db/application/default/models/UsersTable.php

No reference from table UsersTable to table ContactTypesTable

I’m unfortunately stumped. Any ideas?

More on video, you could talk more on the dependentRowset and the magic functions.

$select = $db->select()
->from( …specify table and columns… )
->where( …specify search criteria… )
->order( …specify sorting criteria… );

Here is one question, and I think it is easy.
I was wondering how to print category name in view if u are just sending users to view with fetchAll() method ?

I know that u can use some method call in view which will return category name on its id but I wanna know what is the best way!?

good point! However, I don’t think its wise to make the assumption that your collation will always be so lax. I’m not a db expert (I’m a big fan of tools that abstract the developer away from database implementations), so thanks for mentioning this!

At getContactTypeByName, you dont need to lower the case, since you’re using the latin1_swidish_ci (as seen at the phpMyAdmin) the ci means Case Insensetive, and therefore:
mysql> SELECT ‘NAME’ = ‘name’;
+—————–+
| ‘NAME’ = ‘name’ |
+—————–+
| 1 |
+—————–+
1 row in set (0.00 sec)

without changing the case, unless i’m missing something =)

You don’t need an credit card. You can use your bank account as well. Just look for more information at http://paypal.com/

—

Thanks for the nice tutorial again.

Only i use the model and zend db on an other way.

im from morocco ican’t support you because we have no international credit card , you can put same AdSense

Have not seen this video yet.just during downloading thi video i wana appreciate your struggle.I am sure this podcast is neat and clear as former ones.keep good working.