I'm with problems trying to create a model object that contains an ArrayField with IntegerRangeField as base.
I asked about this on #django, and for @knbk this seems a bug. I believe it may be right.
The initial migration an the table are created fine.
However, when I try to create an object, it fails with a SQL error.
There are no difference if a NumericRange object is used instead.
INSERT INTO "core_integerrangearraymodel" ("field") VALUES (ARRAY['[10,20)', '[30,40)']) RETURNING "core_integerrangearraymodel"."id"
INSERT INTO "core_integerrangearraymodel" ("field") VALUES (ARRAY['[10,20)'::int4range, '[30,40)'::int4range]) RETURNING "core_integerrangearraymodel"."id"
I created a test project, with more details, and some test cases to help illustrate the problem.
ticket_24726.diff​ (4.3 KB) - added by Ederson Mota 4 years ago.
Taking a closer look at the exception generated by one of tests created mentioned above, lead me to some things that I would like to share.
INSERT INTO "postgres_tests_integerrangesarraymodel" ("int_ranges", "bigint_ranges") VALUES (%s, %s) RETURNING "postgres_tests_integerrangesarraymodel"."id"
At this time, it's a method of psycopg2.extensions.cursor.
I wondered if this error will also occur using pycopg2 directly, and the answer is yes.
This is a tricky one to fix. My inclination is that half the fault lies with postgres, and perhaps it could be fixed with psycopg2 as well.
I have raised ​https://github.com/psycopg/psycopg2/issues/313 with psycopg2 to get their feedback.
I think your best shot is to use a NumericRange subtype with an adapter adding ::int4range. Adding ::int4range after the array is impractical as you should know subclass the list instead.
An example implementation is in ​this comment.
I'll think whether we should introduce these objects in the library, I'm not so sure, because usually end users are able to specify a placeholder like %s::int4range and work around the problem without introducing too many details of the Postgres data system into the Python objects.
How would you like to proceed with this ticket? I'm willing to help close this with some guidance.
Fixing this would help my use case!
This patch integrates and updates the contributions from edrmp and dvarrazzo above. The tests pass, but I'm not sure I put the psycopg2 adapter bits in the right place. I guess this is more a proof of concept.
I think there needs to be more discussion about how arrays of range fields should work. Lookups don't work right now, and I'm not sure how they would.
Also, dvarrazzo's suggestion to subclass NumericRange works, but wouldn't that require range objects destined for the database to be created with the adapted subclasses? I'm not sure if that's desired for Django. I'm interested to hear what the core team thinks.
Anyway, I hope this patch is helpful!
I'm unassigning this ticket for now as I don't think I can make progress without some design discussion taking place.
I interacted with mjtamlyn over email, and he asked me to open a PR with my patch.
I guess this isn't ready for review since it's marked "WIP".
#27808 is related or a duplicate.
​PR for #28291 also fixes this issue.
Fixed #28291, #24726 -- Fixed ArrayField with JSONField and RangeFields.