+- 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: DataMapper 1.6.0 (/showthread.php?tid=11358)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]warrennz[/eluser]
@camporter1
You're correct. If you have a controller or a library named the same as your model, they are called first.
Typically I rename my controllers and then use URI routing to keep URI's nice and pretty.
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]OverZealous[/eluser]
@nmac
When you are running custom queries in DM, you always must include the id column. DataMapper uses the ID as the index for the all array.
What happens otherwise is you only get one result, since they all have the "id" of null
@warrennz
No, you never have to force DM to update instead of insert. If you have specified a relationship as has_one, then there can only be one copy of that relationship. That's the point of has_one. If you want multiple relationships, then use has_many.
If you need to keep track of just one older, I recommend creating a second has_one to manage it (DMZ makes this extremely easy, and you just need to add another column.)
If you need multiple relationships, then you'll need to either create a dedicated model to represent those relationships, or use DMZ and join_fields to manage those relationships.
With DMZ, you can set the relationship up as has_many, then add one or more columns on the join table. You can then query against those columns. There's an example in my document of how to use it to keep track of who's seen an alarm that is assigned to multiple users.
@camporter1
Just to clarify what is happening, PHP doesn't have classpaths, so every class is identified uniquely by its name. This is why most DM users use "Object" for the model and "Objects" for the controller. It still looks good, and is easy to read. It's only a problem if you have "Moose" or "Deer" models. ;-)
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]warrennz[/eluser]
@OverZealous
Mhmm, its a little tricky. I originally wanted it to force insert, not force update. But basically I had a 1:N relationship but need to be able to insert the exact same relationship time and time again. If my user id was 1, and my item id was 2, that would typically create an update on the second time I ran a save(); (or no action) as that relationship would have existed already. I needed it to insert every time regardless of existing identical relationships.
But as always, thanks again
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]naren_nag[/eluser]
[quote author="OverZealous.com" date="1240536580"]Is it possible to reset your data, or set up a temporary database, and try inserting 200 items (via code, of course). Just to see if it is repeatable?
Do you have any related validaters?
Can you manually insert another row into the table?
As warrennz mentioned, turn on CodeIgniter's profiling, and look at the exact queries being run.[/quote]
Ok guys,
I just woke up ... and I have a plan:
1. Rewrite the controller (well, not totally rewrite, but you get the idea
2. Add 200 records (via code)
3. See if the problem comes up again.
Expect to hear from me sometime in the next 24 hours. I'm off on a holiday to a place called Goa in India -- beaches etc. and will be coding from there.
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]OverZealous[/eluser]
@warrennz
I recommend using a dedicated model to track those, then. The problem with what you are doing is that there is no way for DataMapper to tell each row apart, since it only uses model1_id and model2_id.
By having a dedicate model, you can track each relationship multiple times. Of course, it can make queries trickier, but if you are using DMZ, they might work pretty well (using same-table has_one fields).
Good luck, and please let me know what you decide to do!
@naren_nag
I'm jealous of your holiday with beaches :-P
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]warrennz[/eluser]
@OverZealous
Mhmm, that makes alot of sense. It's almost as if I don't need a 1:N rel. I mean, there is one account, and many items attached to it which is technically 1:N. However I would only EVER be accessing the most recent one, or in any case only ever accessing 1 depending on passed date values.
So maybe despite the obvious 1:N rel I should just do 1:1 ? Would that be back practice?
Mhmm
Beaches are good
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]OverZealous[/eluser]
@warrennz
I don't have an answer to whether that would work for you or not. In my experience, the best thing to do is to only store the information that you need to store. The more data and relationships you store, the more complex maintenance will be.
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]warrennz[/eluser]
Yea
The app I'm creating is a usercp for the ISP I work at. The customer needs to be able to login and essentially go back in time and see what their account was like at that time (eg what plan they were on,speed/datacap etc). So, the items (plans) need to be stored historically. So I'mm not too sure how I could store any less data but I definitely hear what you're saying. Some of the relationships that currently exist are a bit of a nightmare, hehe - will have to go back and some point and have a bit of a clean up
Ta
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]OverZealous[/eluser]
I think one good, clean solution is to do what I said above, about having a dedicated object to store the relationships.
Say this:
You have Users, Plans, etc.
Create a model called PlanLog (or whatever). PlanLog has single relationships to User and Plan, as well as a start and end date. (Edit: I forgot to mention, User and Plan have many relationships to PlanLog.)
Optionally, don't store an end date on the current one, so you can quickly look it up { $planlog->where('enddate', NULL) }. Alternatively, store the most recent directly on User, as described at the bottom.
You can also create relationships to any other changes you need to track historically.
Then to get the history (using DMZ), you can do something like this:
Code:
$pl = $user->planlog;
$pl->join_related('plan', array('id', 'name', 'speed', 'cap'));
// repeat for anything else you need to print out
$pl->order-by('enddate DESC');
$pl->get(); // you can paginate like normal, here
// $pl->all should have all of the changes, ordered by date
// $pl->plan_name, $pl->plan_speed, etc, will contain plan infoThat solves the problem nicely, I think, and you can still get the latest fairly quickly. If you need, go ahead and store the most plan directly on the User model. Since it is stored as a $has_one, it will automatically replace any old ones. Then just add a new PlanLog for every change.
DataMapper 1.6.0 - El Forum - 04-23-2009
[eluser]warrennz[/eluser]
@OverZealous
Thanks a bunch, your replys are invaluable. I'll have a go at it next time I'm working on it.