+- 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 - 11-01-2008
[eluser]OverZealous[/eluser]
It's been a huge advantage for me (although, you really need to design FOR datamapper). I love being able to almost "ignore" the database in my code.
Good Luck! Feel free to come back if you have any questions.
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]Aukie[/eluser]
You are fast in your replies Phil (Guess thats your real name no?!)
That will be appreciated by many!
I am still wondering what the real advantage is.
Normaly I would make some models who will handle a certain scope of information from the database.
For instance I am working on a real estate website I have user related database tasks and real estate tasks so I have two models with various functions handling database tasks. I than return database objects to my controlers who process and gather the information and serve it to my views.
With datamapper I will have more than two models.
The code is somewhat different from that of codeigniter but not even that big.
I must say I almost always use $this->db->query( ) serving a normal sql query.
As you can see I have not grasped the benefit of using datamapper.
You are wrote "need to design FOR datamapper" to get the real advantage. Do you mean like the naming convention for tables etc?
Is it a conveniance improvement or a real advantage, in using datamapper?
Can you learn me what the advantage realy is in using datamapper, what can you tell me about it?
Next thing i wonder is speed, how is datamapper performance v.s. plain old php mysql queries...
Love to learn!
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]OverZealous[/eluser]
The real advantage is in development time. I don't know how much performance matters, and I won't have answers to that for some time yet, due to the kind of project I am developing.
Where DM shines is in reducing code complexity. For example (I don't know your project, so this is just a guess),
Code:
// get all real estate properties for this user
$user = $this->session->logged_in_user;
$properties = $user->properties->get();I think that is significantly easier to read and work with than the more traditional method. (I won't bother writing that out, but you can guess, running a query, parsing the results, storing them into some kind of temporary object or array, or - shudder - passing the results array directly to your view. :-P )
Where you have to be "careful" is in your application design. Not only tables, but sometimes you might have to rethink something that would be a very complex SQL query. Because DM doesn't allow you to write your own queries, you can sometimes end up running several queries behind the scenes instead of one compound query if you wrote it by hand.
Personally, I think the trade-off is worth it. I'm building a project that would normally take me 2x as long, or require extra people, and I'm doing it on my own. I think DM & CI are really helping chip into that time.
(I live in front of my computer. That's why the response times are so quick ;-) )
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]Aukie[/eluser]
Thank for you answer Phil!
So it is indeed more of a conveniant thing.
I do like conveniant tools and solutions to make my live easier ;-)
I must say that I think that a function in my model like below is easy to write, use and read though.
Code:
public function get_objects( $type, $perPage=6, $ofSet=0 )
{
$sql = "SELECT id, host_id, area, price, image1 FROM objects WHERE type_id IN (".$type.") LIMIT ".$ofSet.", ".$perPage;
$query = $this->db->query( $sql );
if( $query->num_rows() > 0 ){
return $query;
}else{
return FALSE;
}
}DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]OverZealous[/eluser]
Certainly that's easy. Except when you need to add another object type. Or another field to your object. With DM, you can add fields to the DB and have access to them immediately in the object. Of course, it's better to throw them into the validation array as well, but that's a minor thing.
Finally, because it's object oriented, you can start getting really creative with your objects.
For example, say you have a contact with multiple phone numbers, but one number is the "Default". Every time you change the default, you need to unset the previous default. In DM, you can add this to your model:
Code:
// in class Phonenumber
function set_default() {
// gets all other default phone numbers
$others = $this->contact->get()->phone->where('default', TRUE)->get();
foreach($others->all as $o) {
$o->default = FALSE;
$o->save();
}
$this->default = TRUE;
$this->save();
}Now, that's a few lines of code, but it's associated with the model now. What I like is how clean that is to read when you use it later:
Code:
$phone->set_default();As opposed to:
Code:
set_default_phone($contact, $phone);If you aren't used to the OO way of programming, it takes some time to see how it cleans up the code. (It looks like you are more used to functional programming, given your function design ;-))
Also, you don't have to worry about function names too much :cheese:
Finally, I'm not ready to release it yet, but I've developed a really slick way to automatically convert DM objects into form fields or html-ready views. For example, you can get a date-editing field simply by using:
Code:
echo($task->e->datecompleted->date);And it will automatically print out a date field. With a few minor changes to the DM model, you can even eliminate the ->date at the end. Replacing the ->e with ->v will render the date as formatted text, instead. This only works because of the self-aware nature of DM models.
I've got it working for almost every common DB datatype, as well as some specialty items (like email addresses or web links). The only big caveat is that I've written mine around Dojo and Dijit, which not everyone uses.
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]Aukie[/eluser]
Thanks Phil,
You are right I'm more used to functional programmer and did not grasped the full idea about OOP
Maybe diving into datamapper will make my understanding of OOP come to a new level ;-)
Thanks again for answering and your time.
Cheers Auke.
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]m4rw3r[/eluser]
@overZealous, about set_default():
Horrible performance... All I can say about your code: use SQL instead
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]OverZealous[/eluser]
@m4rw3r
I appreciate your concern. I'm certain - and never said otherwise - that a traditional pure SQL variation would have better performance. It would replace the 3 or 4 queries with 2 (depending on how if the Contact is already loaded or not). If you are updating this field constantly, I'm sure you will see a tiny improvement.
However, I don't see anyone changing the field constantly on my end. In fact, most of my code is about reading data back from the DB.
You are allowed your opinion, but if you have nothing to offer beside "horrible performance", then it is merely that - an opinion. There is more to application development than performance, including development time, maintenance and updatability.
If you prefer raw SQL designs, then that is your choice. But please don't bash my choices - it's unproductive for everyone.
DataMapper 1.6.0 - El Forum - 11-01-2008
[eluser]m4rw3r[/eluser]
I was just criticizing that particular piece of code, not anything else.
The performance loss is probably not really *that* important in the large perspective, because there are a lot of other things going on.
As you say, there is maintainability to take in consideration. Normally it would have been about the same. But with the db style of DataMapper, there are the join tables to take in consideration in every relation which makes your method more easily maintained.
DataMapper 1.6.0 - El Forum - 11-04-2008
[eluser]Paul Apostol[/eluser]
Hello,
Anybody used a joining table with 3 tables with DM? I really need such a thing. Or do you have any idea how to split them somehow to work with DM?