How can we link Detail to Master by field with type KEYS

[Zoi Moravec]

Hi all!
A have table Orders and field members_ids with type KEYS

In any order (order_id = 1) there are can be many members. i.e. field members_ids = 1;2;3 (for example)

And i have table Members and 2 some classic Details tables for it.

How can i add Orders table as detail table №3 for Memebers and show the same record with (order_id = 1) for diffrent members with id=1, id=2 and id=3? This like "many to one" linking...

[Dean D. Babic]

Maybe something like:
https://billsofmaterials.pythonanywhere.com/

https://billsofmaterials.pythonanywhere.com/static/internal/bom_1.0.0_7.0.52_2026-05-20_02-49-15.zip

But not sure...

[Zoi Moravec]

Yes, it's nice case, but it would be great include table bom_assembly_subparts not in view-subdetail, but in view-detail in separate Tab (tabs-div).

среда, 20 мая 2026 г. в 05:51:53 UTC+3, Dean D. Babic:

[Dean D. Babic]

It is:

set_where({members__contains: item.id.display_text});

not the:

set_where({members__contains: item.id.value});

Took me a while to figure this out since value produces a tracback! Might be a bug

I do not know how would you display this is a 3rd Detail tab tho. Try to search, ie: https://groups.google.com/g/jam-py/c/uNZrOBVPXeE/m/D0pftkLXAQAJ

[Dean D. Babic]

Sure thx.

If you figure how pls do tell :) I spent heaps time on this since it was an idea from Django. And still not great coz of Summaries.

Here is the schema:
https://billsofmaterials.pythonanywhere.com/static/bom.html

[r rad]

Hi,

I'm not sure what your intention is but I'm think that you are want with KEYS type to have m:n relations in Orders (to Members),

and after that to represent only one side relation Members to Orders. 

I think that it is not supported by current Jam.py. Maybe I'm wrong.

When I it try before ..., in version V5 I have to write some JS code and custom table (with custom PKs) for that. 

But I'm don't know enough V7, maybe somebody to know.

PS. And, how to You think, to get more members for one Order in your KEYS field? 

[Zoi Moravec]

Hi, Dean!

For this case with detailed table and linking KEYS field type it must be corrected check_lookup_refs in db.py (for correct function delete master record and check referenced detail records).

It works for me:

diff -ruN a/db/db.py b/db/db.py
--- a/db/db.py  2026-07-23 08:25:18.477865217 +0300
+++ b/db/db.py  2026-07-23 08:27:10.705864542 +0300
@@ -257,7 +257,10 @@
                    copy = item.copy(filters=False, details=False, handlers=False)
                    field_name = field.field_name
                    #copy.set_where({field_name: delta.id.value})
-                    copy.set_where({field_name: delta._primary_key_field.value})
+                    if field.data_type == consts.KEYS:
+                        copy.set_where({field_name + '__contains': str(delta._primary_key_field.value)})
+                    else:
+                        copy.set_where({field_name: delta._primary_key_field.value})
                    copy.set_fields([field.field_name])
                    copy.open(expanded=False, limit=1, connection=connection)
                    if copy.rec_count:

четверг, 4 июня 2026 г. в 22:23:47 UTC+3, r rad:

[Dean Babic]

Thanks

Could you record a video, maybe some other demo if cant show your data?

On Thursday, 23 July 2026, Zoi Moravec

 <zoi.m...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "Jam.py Users Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jam-py/jazIICmV8nU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jam-py+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jam-py/0071dca4-fac2-40e0-9721-dce521addfa6n%40googlegroups.com.

[r rad]

Hello,

First of all, kudos for the code. Really.

But...
I'm not sure it's a good idea to change one of the basic premises of the framework - surrogate primary key values.
And that for a very specific application, the like of which I have not yet seen.

As I can see, you are very skilled with coding and that's why I think you should enclose this code in your specific item.

One of the variants of saving PK behavior is to move the story to a unique key.

In both cases I would ask the question, 

"How to ensure the uniqueness of the linear combination of your BOM or more simply, what to do when a material with the same BOM specification appears?"

The next question is a bit more theoretical, actually the BOM can be a very large set of participating materials, and then of course the technical question of 

operability arises, such as first of all the speed of working with such keys and then the question of accommodation.

I think the author had a completely different idea of ​​using this type of field.

As I already wrote, I also wanted to make something similar to the SELECT2 control, which leads to a little m:n relationship, but it really didn't occur to me 

to further branch relationships by that field.

Anyway very good code.

Greetings.