Why assn tables don't get more than 2 fields?
Wed, 01/28/2009 - 12:04
for example:
I have 2 tables orders and products.
i have to make an assn table order_details which has 3 fields
oder_id ->orders.id
product_id->products.id and
amount.
I solve this by (copy-paste) writing the orderdetail class and meta class by myself.
In a future release of QCube,I belive, it has to generete it automatically.
Supporting more then two fields in ASSN and TYPE tables is definitely something I want to do.
Currently, we're in a feature freeze as we push towards a 1.0 release, after that, all suggestions are on the table.
Folks - I actually added support for more than 2 fields in the type tables a long time ago, and Mike Ho added it to QCodo (and it is in QCubed right now).
I have updated the example for Type Tables for QCubed RC2, so if you sync from QCubed SVN, you'll see the sample code. And when RC2 comes out, it'll of course be in one easy download :-)
It would indeed be great to add support for more than 2 fields in Association tables.
There's no reason not to create a feature request ticket for this, so here it is:
http://trac.qcu.be/projects/qcubed/ticket/152
You'll note I've already commented on it. Basically, while I like the idea, I'm totally unconvinced it's implementable.
Are you issuing a challenge? :-)
LOL, yes!
I encountered the need for this myself.
Logically I would envision it working as followings.
Say we have these tables:
user: ID, Name
user_hat_assn User_ID, Hat_ID, Hat_Size
hat ID, Name
Just for a second ignore the logic of placing Hat_Size on user_hat_assn. In this instance, let's assume that we don't want to populate Hat with millions of largely similar hats that all differ only with regads to size. In real life, you might want to actually do the latter for some reason. In this case, we want Hat_Size to be associated with the relationship between user and hat.
Now, how do we access Hat_Size?
Logically, I see it happening as follows:
If I issue the call:
$user->GetHatArray();
Then for each Hat instance the virtual property Hat_Size will be set to the Hat_Size value implied by the user_hat_assn for that particular relation.
Similarly, if I do:
$hat->GetUserArray();
Then for each User instance the virtual property Hat_Size will be set to the Hat_Size value implied by the user_hat_assn for that particular relation.
As far as I can tell this is a simple and logical of approaching the matter for additional fields on association tables.
Comments?
I like that approach for retrieving hat size.
It's the setting that has me challenged.
Perhaps I'm making this harder than it has to be though. The codegen template may just need to look something like:
Associate<%=$class%>(<%foreach($additionalColumn as $column){echo '$',$column->Name;}%>){
<%foreach($additionalColumn as $column){
echo '$', $column->Name, ' = QDatabase::Parameter(QType::Cast($', $column->Name,', ', $column->DataType,"));\n";
}%>
$sql = 'insert' etc
}
Vexed - I like the proposed codegen template mod. Looks great!
Is this in a ticket? Definitely want to capture this.
Yep. http://trac.qcu.be/projects/qcubed/ticket/152
Hello Alex
Could you create a path against the trunk
regards
enzo
I'm afraid I don't have time to do it right now - all my QCubed energy is going towards the 1.0 release. Creating a patch based on what Vexed provided should be reasonably doable - if you end up making it happen, please do share the patch!
Otherwise, this will have to wait when we get 1.0 out the door (next month or so)
Has there been any progress on this issue? I was wondering if there are any plans to have it included in a future release.
It was planned for 1.2, but since we're basically scrapping that release, it was mostly in limbo. I've moved the ticket to 2.1.0 which will be the next feature-improvement release. :)
I see no reason to delay this any more than it already has been. :)