IgnitedRecord 1.0 pre-release

[eluser]Tim Stackhouse[/eluser]
Good to know, and thanks for making such an awesome library, but I even tried setting the cascade_on_delete option to false and it still was letting me delete from my roles table when I had an ON DELETE RESTRICT on the users_roles table. I ended up just earlier this afternoon doing a check if there are related users to a role before allowing deletion of the role.

In terms of DB layout, and the cascade, with the exception of many-many relationships shouldn't the FK reside in the belongs_to model? That is:

My current project has a basic structure like this:

User
|->Symposium
| |->Session
| | |->Presentation
| | |->Presentation
| | |->Presentation
| |->Session
| | |->Presentation
| | :
| :
|->Symposium
:

The way I have it laid out, symposium has a user_id field, session has a symposium_id field and presentation has a session_id field. That layout wouldn't need any nulls, and from a data integrity standpoint, if i blew away an entry in User and it DIDN'T cascade, that would corrupt my data.

I'm probably being terribly redundant and restating something that quality programmers recite as mantra, bu t does that sound logical?

[eluser]Tim Stackhouse[/eluser]
That actually raises another question, I'm not sure if I'm doing it right, but adding a relation, e.g. symposium->add('user', $this->user) my foreign key check fails and the query it spits out doesnt have a user_id field in it. Am I doing something wrong or is my DB and/or relation configured wrong? I've got it working by doing the equivalent of $symposium->user_id = $this->user->id, but this seems less than ideal.

[eluser]m4rw3r[/eluser]
About the first post, yes the foreign key lies in the table which uses the belongs to relationship type.
And if you accidentally deleted a user, you will have symposiums which hasn't got a related user.

Second post: I don't know why it is acting like that - can you please PM me some SQL generated by that call?

EDIT: And IR cannot change the behaviour of the ON DELETE RESTRICT (it doesn't change anything except for the data)

[eluser]Tim Stackhouse[/eluser]
I'd be happy to send along the relevant info, how can I extract the queries it's generating?

[eluser]m4rw3r[/eluser]
CodeIgniter's profiler, it is quite good.

[eluser]Tim Stackhouse[/eluser]
Good to know, I'm learning more and more about CI every day. (A heck of a project for my first crack at CI) I've sent the relevant info along.

[eluser]Tim Stackhouse[/eluser]
I hate constantly asking about stuff like this, but it seems like chaining references doesn't work as such:

Code:

$q = $session->related('symposium');
$symposium =& $q->get();
$q = $symposium->related('user');
$user =& $q->get();

I'm getting "IgnitedQuery: Cannot generate SQL-query - the from part of the query object is empty." when I try to run that code.

I've worked around it at the moment by doing a join_related('symposium') before my find(), than doing a $session->symposium->related('user'), but at least to my eyes it seems less than ideal, especially in the next round I'll need to traverse another level up, specifically, $presentation->session->symposium->user. Any imput is appreciated.

[eluser]m4rw3r[/eluser]
Are you sure that symposium really have a relation named "user"?
Because if the relation doesn't exist, IgnitedRecord will return an empty query object.

[eluser]Tim Stackhouse[/eluser]
It does. I have a $belongs_to = 'user' in my symposium model. What gets me is that I can do:

Code:

$this->Session->join_related('symposium');
$session = $this->Session->find($id);
$q = $session->symposium->related('user');
$user =& $q->get();

And it works just fine and I get all my related records, but if I do:

Code:

$session = $this->Session->find($id);
$q = $session->related('symposium');
$symposium =& $q->get();
$q = $symposium->related('user');
$user =& $q->get();

It returns just fine? That code was giving me an error yesterday. I swear I must be making up problems... This has happened two or three times... I had code that gives me an error, post about it, than the next day it works... I feel like an idiot. :p

EDIT: I figured out what I was doing wrong that was causing that error. I have BOTH the call to join_related() and related() so I was essentially running a combination of both those blocks of code. In case anyone is running into the same problem, that's what was happening.

[eluser]Tim Stackhouse[/eluser]
I know that it's a thirdparty thing, but I'm getting odd behavior out of acts_as timestamped. When I create a record as such:

Code:

$symposium = $this->Symposium->new_record();
$symposium->load_data($data);
$symposium->add('user', $this->user);
$symposium->save(true);

It's not populating created_at. It's populating updated_at just fine, but it's like I have created_at turned off. I can set it manually in the DB and it shows up fine, but it's not automatically populating. I've tried every combination of settings I can think of, but nothing works.

EDIT: I've figured out part of it. I defined my columns as timestamps and my DB admin app was too smart for its own good and added a default current_timestamp and on update current_timestamp to the updated_at field. That explains why I was getting values for updated_at, while not getting anything for created_at.

Looking over the logs after turning the level to debug, I'm not seeing the behavior loaded message, there's not something I need to do besides adding var $acts_as ='timestamped' is there?

EDIT EDIT: I truly am an idiot... it's $act_as NOT $acts_as. Now to wallow in my shame... :p