DataMapper 1.6.0

[eluser]OverZealous[/eluser]
@quasiperfect
This has been covered many times on this board. You still must save the new objects first. $obj->save() will only save $obj to the database, and any related items.

[eluser]bEz[/eluser]
[quote author="quasiperfect" date="1237561555"]i'm using the original datamapper

what i want to do is this

save a new object let's say user (it doesn't exist in the db that's what i mean by new)
save a existing group to this user
save 2 new (it doesn't exist in the db that's what i mean by new) books to this user
all of this in one shot so if one save fails i need all the thing to fail

my code is

Code:

$u = New User();
$u->name = 'test';
$g = New Group();
$g->where('id','1')->get();
$b = new Book();
$b->name = 'b1';
$bb = new Book();
$bb->name = 'b2';
$u->save(array($g,$b,$bb));

the problem is that it saves the user it saves the group relation but not the books

i looked at the debug data and it doesn't even try to insert the books or the relations between the books and user
any idea ?[/quote]

@quasiperfect
Based on the reply from OverZealous,
What is the (or is there a) relationship between user and book?
Also, which version are you using: DM or DMZ?

[eluser]OverZealous[/eluser]
@bEz
He says he's using the original RIGHT at the top of your quoted section.
Also, it doesn't matter which version. You always have to save objects before saving relationships.

I also think I should clear something up. This:

Code:

$g->save();
$b->save();
$bb->save();
$u->save();
$u->save($g);
$u->save($b);
$u->save($bb);

and this:

Code:

$g->save();
$b->save();
$bb->save();
$u->save(array($g, $b, $bb));

Do the exact same thing! DataMapper doesn't do anything magical to make the save take less writes to the database. It is just cleaner to read.

[eluser]macigniter[/eluser]
[quote author="cahva" date="1237556630"]
Sorry have to comment this one. Have you absolutely told the client the benefits of PHP5 and told them that PHP4 is at the end of its road as its discontinued over a year ago? Old sites will usually work with PHP5 also and you can set a few configuration values to PHP if theres old-skool usage of register globals, long arrays(eg. $HTTP_SERVER_VARS, $HTTP_POST_VARS etc.).
[/quote]

I have tried to convince them with lots of arguments, but they are running several old scripts on the server and since money is an issue for everyone these days there is no way of running the new application on a seperate server without porting their old data. I'd really rather run it on PHP5

I was also thinking of using an .htaccess file to switch their old applications to PHP4. Do you think that would be a viable solution?

[eluser]OverZealous[/eluser]
I forgot to mention that when I googled php4 __get, the first link turned up some ways to get __get-like functionality working in PHP4. It was a long article, so I didn't actually read through the whole thing.

Also, check out http://hurring.com/scott/howto/php4_and_php5/ for tips on getting PHP4 and 5 running together on one server. (An .htaccess file should work just as well).

It looks like it isn't too difficult to get php4 running in one directory, and php5 running in another. I think that's definitely your best option!

Alternatively, since CodeIgniter has only one startup file (index.php), you might be able to rename that one file .php5 (if the server is configured for it), and just update your config.

[eluser]wolffc[/eluser]
I have a mysql question for everyone. In your pivot tables or you put each column in its own index or put all 3 of the columns in one index? I am not really sure what is best.

Thanks

[eluser]Oblique[/eluser]
Hi. I'm not experienced in DBs so what you'd advice in this situation:
We have table complaints and sometimes (but not every time) complaint has optional feature named otherType.
I decided to store them in a table otherTypes that looks like
complaint_id(INT) | otherType(TEXT)

so i don't loose disk space with unset fields directly in complaints table.

Question is: can this be done with support of DM?

[eluser]wolffc[/eluser]
How i handle things like that with datamapper is build a table of types and then have a pivot table point the complaint to the type.

complaints -> complaints_othertypes -> othertypes

This way you could have complaints with multiple other types.

then you have an easy way to access this

$complaint->othertype->get() //will get all your other types for the complaint

you can alls do a reverse lookup

$othertype->complaint->get() //get all the complaints of a specific type

[eluser]Oblique[/eluser]
Well thx, but i understood this part from reading the manual 8)
The usual approach using complaints_otherTypes table doesn't make sence here, that's why i wanted a piece of advice. Let me explain more deeply:

complaints has field "type" and there are some particular values of type, when user of DB enters something and it goes to the otherTypes. So i want to avoid giving complaints table additional field to describe typeOther because probably there will be no typeOther for the most of entries.
It means when type takes one of magic values, i look for type in otherTypes not in types...
Of course this mechanism is slightly clumsy.
And that's why i need an advice 8)

[eluser]OverZealous[/eluser]
@Oblique
First, how much space are you really going to waste having one extra null field? Have you done any research? I think you you are over-complicating something unnecessarily.

Also, it appears that the type field is a number, correct? Instead of storing the type number directly in the complaints table, why don't you relate Complaints to a generic ComplaintTypes table. Then, pre-fill in the default values on the table.

Now, when someone chooses a default type, you simply relate that item. If they add a custom type, you save it to ComplaintTypes, and relate that one. Now you don't have to do anything special to deal with "other" types vs "normal" types.

One benefit of this method is, if there isn't a security risk, you could actually use a little JavaScript to suggest values from the Types table as someone is typing them in. This may or may not work depending on your users, what gets typed in, and if you want to maintain that.

If you are using my extended version of DataMapper, you don't even have to add an extra table to join the two, you can just add a column complainttype_id to your complaints table.