Welcome Guest, Not a member yet? Register   Sign In
IgnitedRecord 1.0 pre-release
#71

[eluser]Palino[/eluser]
hello,

is somebody working with IgnitedRecord and HMVC (ME) together? What do you think about? Any problems, issues...

Regards

Pali
#72

[eluser]m4rw3r[/eluser]
I haven't worked with HMVC(ME), but I think HMVC(ME) uses the overriding Controller class as the Loader (this is just my conclusion after a quick glance, correct me if I'm wrong).

I guess you wonder how to add the MY_Loader class and how to get it to work?
According to my guess, you should copy the orm() method from the MY_Loader.php file and add to the the HMVC(ME) Controller library file (in the Controller class).

Anyway, I don't see any problems that could arise, but I haven't had a close look at HMVC (ME).

BTW. The development of version 0.2 is going great, not so much left Big Grin
#73

[eluser]sophistry[/eluser]
NOTE: EDITED shortly after publish.....

i've tried it and it seems to work, but you have to put the ignitedrecord/ignitedrecord directory that holds the models in the application models directory rather than the module directory. or you can just put the files in the ignitedrecord directory in the distribution right in the application/modules/modulename/models dir. when you use HMVC/ME you can't have models in a sub dir of the module. anyhow, it works either way and you can set it up however you like.

on another note, i just grabbed the SVN version and i had to change my column names for foreign keys from plural_id to singular_id. i used to have FK groups_id and users_id and it worked in the latest build but after putting the latest SVN (v02) i had to change the column names to group_id and user_id. that should be noted in the changelog.

finally... nice work on the manual - it's really much better organized now.

thanks.
#74

[eluser]m4rw3r[/eluser]
Another solution would be a file with the name "ignitedrecord.php" that looks like this:
Code:
<?php
require 'ignitedrecord/ignitedrecord.php';
Put it in the models dir and you're done!
You can then load IgnitedRecord via $this->load->model('ignitedrecord'); in the modules.

@sophistry
It is now added to the changelog, thanks!

@all
Your thoughts on placing all IgnitedRecord files in a separate directory in the model?
Is it good? or bad (like in the ME case)?
#75

[eluser]sophistry[/eluser]
thanks!

i think it's tidy to keep everything in a subdirectory. the ME case is not a standard setup and if someone is working with ME they should be prepared to do some level of integration (IMHO) with any other resources they are working with.
#76

[eluser]Hannes Nevalainen[/eluser]
Let's say i have a Users table and a Blogs table. Every blog entry belongs_to an User and an User has_many Blogs.

When using SQL (AR) you would typically use a join when listing all Blogs like this:

Code:
$this->db->join('users','users.id = blogs.user_id','left');
$this->db->get('blogs');

//Produces something like "SELECT * FROM blogs LEFT JOIN users ON users.id = blogs.user_id"

Is there a smart way to get all data just using one query in IgnitedRecord?

Code:
//For READ-ONLY purpose I think I can do this:

$this->db->join('users','users.id = blogs.user_id','left');
$blogs = $this->Blogs->find_all();

//The downside is that the you would get your data like this:
foreach($blogs as $blog){
  echo $blog->username;
}
//I think it should be like this
foreach($blogs as $blog){
  //User is an IgnitedRecord_record record..
  $blog->user->username;
}

I think it would be faster to make a single query if you are going to display many blogs from different users (don't know, but it seems reasonable)

Thanks for a G R E A T lib anyway!

Regards
//Hannes
#77

[eluser]m4rw3r[/eluser]
I've already tried it with splitting it up in different objects, but there are a few disadvantages (see this post).

The disadvantages are these:
* Performance loss
* The columns may overwrite eachother if you don't prefix them correctly (so the uid columns can link to wrong record :bug: )
* A lot of code, which has to be adjusted depending on the type of query
* May have problems with Has Many and HABTM relations (eg. you get three of the same row, because there are three related rows)
* Loss of flexibility

The only advantage as I see it is that you can alter and then save the related objects.
You can't save the joined data when they are joined without objects, but you can save the "original" data.

The unfinished version 0.2.0 does have a join_related() method, but it works by prefixing the related columns and then it does nothing else.
It only works with Belongs To and Has One, because of the above mentioned problem.
It is also only a subquery, so it is not a "real" join, and because of that it can only return records which are related to the joining table (the reason behind making it a subquery is that it provides a lot more flexibility, and affects the user's SQL code less).

So in your case the code will be like this:
Code:
$this->Blogs->join_related('user'); // singular, because it is a belongs to relation (just a default value :P )
$blogs = $this->Blogs->find_all();

foreach($blogs as $blog){
  echo $blog->user_username; // now, by prefixing, you won't have them interfering with eachother :)
  echo $blog->user_email; // just a more nice-looking example
  echo $blog->text; // the normal properties are unchanged
  echo $blog->date;
}

// produces something like this:
SELECT *
FROM
(
    SELECT `id` AS user_id, `username` AS user_username, `email` AS user_email
    FROM `users`
) AS related_user,
`blogs`
WHERE `blogs`.`user_id` = related_user.user_id

I may take a look at splitting it up in different objects in a later version.
#79

[eluser]m4rw3r[/eluser]
Very interesting article, but what is your point?

I can only guess what you meant, and I guess that you want to say something like this:
"An ORM is very good up to a certain point, and after that use pure SQL because of flexibility and performance."

If that is what you meant, I agree with you.
If not, please explain.
#80

[eluser]sophistry[/eluser]
I wasn't driving at anything in particular! but, it certainly wasn't to advocate adopting ORM and then abandoning it.

i merely thought it was an instructive article which touched on exactly the points you raised WRT Hannes' suggestions/feature requests. There is an "impedance mismatch" between ORM and SQL and in between is a series of tradeoffs, compromises, and arbitrary (read: site specific) decisions that need to be made.

I, for one, prefer abstracting a well-designed data model to objects and am willing to tradeoff *quite a bit* to get away from the direct manipulation of the data using SQL. it's one of the reasons i was drawn to CI in the first place and i am pleased to see this ORM lib in such a fine form.

cheers.




Theme © iAndrew 2016 - Forum software by © MyBB