Code behaviour: Working object orientated with a database I'm working on my own PHP framework for a long while now.
Right now I'm in a refactoring process.

I'm came up with the question what a programmer would excpect what happens when he see following code:

// working object orientated with a database.

$UserGroup = new UserGroupModel();
$UserGroup-&gt;Title = 'Guest';
$UserGroup-&gt;Insert(); // execute sql

$User = new UserModel();
$User-&gt;Name = 'Peter';
$User-&gt;UserGroupID = $UserGroup-&gt;UserGroupID;

// print all users
print_r($UserGroup-&gt;Users);

$User-&gt;Insert();  // execute sql

// print all users
print_r($UserGroup-&gt;Users);


Would you expect that $UserGroup->Users imeditaley contains the reference or after the  statement $User->Insert();.

(Currently it is the second one.)

The same with an update statement:

// lets pretend we got the $UserGroup1 and $UserGroup2 from the database


$User = $UserGroup1-&gt;Users[0];
$User-&gt;UserGroupID = $UserGroup2-&gt;UserGroupID;

print_r($UserGroup1-&gt;Users);
print_r($UserGroup2-&gt;Users);

$User-&gt;Update();

print_r($UserGroup1-&gt;Users);
print_r($UserGroup2-&gt;Users);


Would you expect that $UserGroup->Users imeditaley contains the changed reference or after the  statement $User->Update().
(Currently it is the first one.)

Because working with new Objects and already existing ones behave differently I thought it might could be confusing.
My suggestion would be that the reference is updated imeditaley.

At the moment references for new Objects aren't updated imeditaley because the reference is based on the primary key that doesn't exists yet. It exists after we run Insert().

Maybe I could solve this problem by working internal ids and not database ids.

But the real question is, what would you expect what happens (for the references) without reading any documentation?

EDIT

@showerhead

If I got you right, you would consider this as an better way:

$UserGroup = new UserGroupModel();
$UserGroup-&gt;Name = "...";
$UserGroup-&gt;Save(); // runs an insert or update sql statement

$User = new UserModel();
$User-&gt;Name = "...";
$User-&gt;UserGroupID = $UserGroup-&gt;UserGroupID;
$User-&gt;Save(); // runs an insert or update sql statement


print_r($UserGroup-&gt;Users); // would be still empty here

$UserGroup-&gt;LoadChanges(); // load the changes

// now we have the new reference in $UserGroup-&gt;Users
print_r($UserGroup-&gt;Users);
Without reading any documentation, huh? Well let me read you your code as I see it then.


Create new Author
Give it a name(instead of title? or is that really the book too?)
Add it to the database.
Create a new Book
Give it a title
Assign it an author using initiated author class
Print Author's books, which is empty
Add book to database
Now, maybe with an update, I would expect Author to have the new book


Your second bit of code is just confusing. Why would you allow your properties to be reassigned? The author isn't going to change. If there are multiple authors, then I would expect you to have a setAuthors() method that accepted an array, or multiple arguments.

Otherwise this looks fine.

Edit

Still not sure if I understand, and changing the example didn't help. If anything it confused matters. Don't delete contents or drastically change it. Just add an Update or Edit section like I've done in my post. Let's see if I can clear up some of these misunderstandings.

Your main question seems to be how I would expect the contents of $UserGroup to be updated. You are right, I originally misunderstood you. So long as I am not misunderstanding you now, this update should help. Anything that caches information, even just temporarily in local scope, I would expect to need to check periodically for updates. Because the content of $UserGroup is "cached" (or should be), I would not expect any change to be immediately available to it. That being said, I also would not expect $User to be responsible for this. $User is a completely separate class and should not be concerned with $UserGroup at all. Instead $UserGroup should explicitly request new data from the database when it anticipates that the data may have changed.

Your comment leads me to believe you also would like to know how this update method would look. I think I just explained it, but essentially it will do what you are already doing when you first initialize the object, it should fetch the new data from the database to replace the old. To be efficient, you should have some sort of check to see if any changes were actually made before requesting the new data. In other words, you would reinitialize the object.

Next you ask the same question again, but say you are using a different method from when you first asked the question. I'm assuming this is a typo from when you updated your question, so I'll skip over this.

The problem with updating the $UserGroup immediately, through the $User object, is that the $UserGroup has no control over it. This means that information could change in some other part of the application, and you would never know because you did not expect it. An example of how this might be a problem: Say you have initialized this object and call another method, and, unbeknownst to you, it changes the information in your object. You didn't expect it, so you continue using it and now indices could be messed up and, using the new example you gave, you could be giving out someone's password to a completely different user. This is why I said earlier that $UserGroup should be concerned with its own data, nothing else should touch it. The best way to do this is to just not load the data until after you have already made all the changes you need to make.

The last two statements about referencing the data is just confusing. Of course you should be using internal indices. When you fetch data from a database, it is no longer associated with that database. It will now have its own reference pointers you should use, usually array indices. When its time to update the database with the new data, then you will use references common to both. For instance, in the $UserGroup database, you might use a user's username or ID to reference the proper cell in the database. These are pretty typical primary keys because they are unique.

I hope this better answers your question. I'm sorry I can't help more, but I"m having difficulties understanding what you are trying to say. I'm assuming because of some language barrier.