DataMapper ORM v1.8.1

[eluser]WanWizard[/eluser]
I didn't say I would stop support for Datamapper. But before I make alterations to the way Datamapper interacts with CI's core, I'd like to see where the core is going. Because currently, I haven't got a clue...

[eluser]Shauna Gordon[/eluser]
Hey WanWizard,

Thanks for keeping this project going and putting up with the CI core team.

I had a question, but after some digging, found that the issue I was having was due to modifications that had been made by the person I inherited my projects from. I can't delete my post, so I'll just leave it up as a thank you.

[eluser]IgnitedCoder[/eluser]
Not answering any questions here just want to say that I'm using DM in all of my projects. In fact I'm forgetting how to use ActiveRecord code all together. If I had a say in the matter I'd make sure that DM was part of the CI reactor functionality by default. RoR has one, CakePHP has one why not CI, plus DM's performance when tweaked is awesome.

@WanWizard, thanks for making it so that I don't have to write long drawn out Models code. If we ever meet I'm buying the first round.

Thanks

[eluser]yoast[/eluser]
I've got a question that I can't find in the documentation.

The situation is as follows. I have a table (B) that has two connections (1 and 2) to the same other table ©.

Situation:

table A
id
b_id

table B
id
c1_id
c2_id

table C
id
d_id

table D
id
code

Now I am trying to use a where_related, and tables B and C are in the middle if the query. How do I force it to take route 1 or 2 in the joins?

$t->where_related('A/B/C/D','code', 'x')

Is this possible when using the where_related at all?

[eluser]yoast[/eluser]
I've got a new issue, which could be a bug (or feature).
There are three models, they have the following relations:

A has one B (can be null)
A has many C
B has many A
B has many C
C has one B
C has one A

I fill this table by:
1. importing A without reference to B,
2. importing B and C
3. Update A with the references to B.

At step 3 datamapper generates strange queries, where it updates all other A's with NULL that have the same B as the one we are about to add to the current A.

[6] => UPDATE `A` SET `B_id` = NULL WHERE `A`.`B_id` = 8 AND `A`.`id` <> 1
[7] => UPDATE `A` SET `B_id` = 8 WHERE `id` = 1

Is this behaviour as it should be? It seems to be enforcing that I only use a B once with an A.

[eluser]WanWizard[/eluser]
You can only define parallel relations using advanced relationships. And you have to name them differently. You will have to use that name when you run the query, not the name of the class.

As to your second question, that should only happen if it is a one-to-one relation (i.e. both sides of the relation use has_one).

[eluser]yoast[/eluser]
Thanks, my first question is now solved :-)

Concerning the second, There is no one to one relation defined on both sides, I just checked.

[eluser]WanWizard[/eluser]
What is the code you use to perform step 3? So what exactly generates those SQL statements?

I checked the datamapper code, but it only does that when:
- the relationship with the related object is an has_one
- the current object has the foreign key

It does not check the other side of the relationship, so it interprets the has_one here very strict.

Update the relation from the other side to avoid that:

Code:

$a = new A(1);
$b = new B(8)
$b->save($a); // relate B to A)

[eluser]yoast[/eluser]
The code that generates the "query" (using datamapper of course) is generic, as we are importing multiple CSVs to the database, where one CSV can have multiple target (or source) tables. We have devised a language to allow insertion of many to many, one to many and many to one relations. One to one we did not need.

Of course I could see this as a many to one relation from B, and we have some code making that possible. Tomorrow I will take a look if that approach works.

Thanks again for your help! I've never seen a guy so devoted to support!

[eluser]yoast[/eluser]
Hmmmm. I just removed table C out of the equasion, and then it saves without any problems, although
- the relationship with the related object is an has_one
- the current object has the foreign key

A has one B (can be null)
//A has many C
B has many A
//B has many C
//C has one B
//C has one A

Strange... It seems that the presence of table C enforces a reciprocal 1 to 1 relation between A and B. Is that possible?

Edit: After removing the relations and adding them back in, it is working! I compared to the latest in the SVN-repository, and there are no changes. Twilight zone!

Probably something went wrong with copying to the test environment...