IgnitedRecord 1.0 pre-release - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20) +--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22) +--- Thread: IgnitedRecord 1.0 pre-release (/showthread.php?tid=7996) |
IgnitedRecord 1.0 pre-release - El Forum - 05-04-2009 [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? IgnitedRecord 1.0 pre-release - El Forum - 05-04-2009 [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. IgnitedRecord 1.0 pre-release - El Forum - 05-05-2009 [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) IgnitedRecord 1.0 pre-release - El Forum - 05-05-2009 [eluser]Tim Stackhouse[/eluser] I'd be happy to send along the relevant info, how can I extract the queries it's generating? IgnitedRecord 1.0 pre-release - El Forum - 05-05-2009 [eluser]m4rw3r[/eluser] CodeIgniter's profiler, it is quite good. IgnitedRecord 1.0 pre-release - El Forum - 05-05-2009 [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. IgnitedRecord 1.0 pre-release - El Forum - 05-06-2009 [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'); 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. IgnitedRecord 1.0 pre-release - El Forum - 05-07-2009 [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. IgnitedRecord 1.0 pre-release - El Forum - 05-07-2009 [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'); And it works just fine and I get all my related records, but if I do: Code: $session = $this->Session->find($id); 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. IgnitedRecord 1.0 pre-release - El Forum - 05-07-2009 [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(); 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 |