GNOME Bugzilla – Bug 625536
Formatting: Custom: Choices from Related Records ignores Relationship Via
Last modified: 2010-09-09 10:26:06 UTC
Version: Glom 1.14.5 on Kubuntu Lucid 32 I used Glom to define 3 tables charger: charger_id (primary key) ... charge_rate: charge_rate_id (primary key) charge_rate_ma charger_id (same value for several but not all rows) ... charge: charge_id (primary key) charger_id battery_id charge_rate_id ... For the charge table I used Developer:Relationships for this Table to define a one-to-many relationship called "charge_rates": charge:charger_id -> charge_rate:charger_id Then in Developer:Layout for the charge table I: - Highlight field charge_rate_id and click Formatting button - in Formatting section, select Use custom formatting - in Choices tab: * select Choices from Related Records * choose Relationship: Charge Rates Via: charger_id * choose Field: Charge Rate ID * choose Also show: Charge Rate mA * check the box Restrict data to these choices Back in the Charge data entry window: 1) I enter an existing charger_id. 2) The Charge Rate ID entry box now has a drop-down selection of available Charge Rate IDs. But the drop-down has *every row* of the charge_rate table, rather than just the rows where charger_id = value I entered in step (1). It looks like an SQL SELECT that's missing its WHERE clause...
Thanks for the bug report. To save me a few minutes, could you maybe upload your .glom file?
Created attachment 166967 [details] PostgreSQL dump file for my_dessert database
Created attachment 166970 [details] .glom file for my_dessert database
I created a "my_dessert" database that illustrates the problem more cleanly. Attached above are the PostgreSQL dump file to create the database, and the associated .glom file. The my_dessert database allows you to choose a dessert type (ice cream, yogurt, fresh fruit) and flavor. The flavors choices in the drop-down selection are supposed to depend on the dessert type chosen, but instead all flavors of all dessert types are always shown.
Thanks (I did receive it via email too). It is currently meant to show all records, ignoring the values of the IDs in the from and to tables. That's what you want for your first ID field. But I agree that a) It's not at all obvious that that's how it works. and b) It would be very useful to make it use the whole relationship, as in your second ID field, as a way to gradually reduce the choices. So I am adding a "Show All" checkbox there. But I think it's a big-enough change that it must go in Glom 1.16. I'm working on it in this branch and hope to have it done in the next few days: http://git.gnome.org/browse/glom/log/?h=feature_choices_show_all
Super, thank you Murray! Looking forward to Glom 1.16. :-)
That is in glom 1.15.2 (and unstable release on the way to glom 1.16) but now I see that you also really need the second field in the choices list to be a related field, instead of just a field in the table itself, so you can show the flavor name. I'll try to do that too. It seems generally useful. It will complicate the field formatting UI a bit though.
Agreed that allowing the "also show" second field in the choices list to be a related field would be very useful in cases like the "my_dessert" layout where the first field is a surrogate key with little inherent meaning. It's been long enough since I've used FileMaker that I've forgotten whether it can do this. Don't remember that it could, though. It's cool to see Glom's features surpass those of its inspiration.* :-) Thanks again for working on this. I upgraded to Kubuntu Lucid just to be able to use the recent Glom package. Very much enjoying the FileMaker-like ease of creating, modifying, and maintaining new databases. * Of course, it did from the start -- by running on top of the truly industrial-strength PostgreSQL backend.
(In reply to comment #7) > now I > see that you also really need the second field in the choices list to be a > related field, instead of just a field in the table itself, so you can show the > flavor name. > > I'll try to do that too. It seems generally useful. It will complicate the > field formatting UI a bit though. That's done in git master. Unfortunately, it's not likely to be in Glom 1.16 (in the glom-1-16 branch in git), because of all the changes that were needed. And git master needs GTK+ 3.0.