Open divyenduz opened 4 years ago
This is a test-utils
error. Currently it only supports String
and Int
ids. Any suggestions on how to make dates unique?
No idea yet! For now, we are only creating 2 records so maybe just removing this guardrail works already! But I can't think of any other way than "peek and regenerate date on collision".
Currently it only supports
String
andInt
ids. Any suggestions on how to make dates unique?
What is the connection between DateTime
and ids? The @id
of this table is an Int
, and the DateTime
field is not unique.
Am I missing something?
I might be wrong (Matic can confirm) but I think the error comes from the next table/model. test-utils
crashes when forming the query for it.
I will look into the code later today and validate this.
That would make sense:
CREATE TABLE `zfah5_banner_tracks` (
`track_date` datetime NOT NULL,
`track_type` int(10) unsigned NOT NULL,
`banner_id` int(10) unsigned NOT NULL,
`count` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`track_date`,`track_type`,`banner_id`),
KEY `idx_track_date` (`track_date`),
KEY `idx_track_type` (`track_type`),
KEY `idx_banner_id` (`banner_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
model zfah5_banner_tracks {
banner_id Int
count Int @default(0)
track_date DateTime
track_type Int
@@id([track_date, track_type, banner_id])
@@index([banner_id], name: "idx_banner_id")
@@index([track_date], name: "idx_track_date")
@@index([track_type], name: "idx_track_type")
}
@@id
and one of the field is DateTime
.
We could probably get away with choosing a random DateTime
value here, with the little amount of data we create? (Could test-utils
maybe have a list of previously generated values for the column, and recreate if a clash is encountered?)
@janpio I suggest we use iteration
number as identifier for now and change the min max property of the date accordingly.
I am still unsure I understand the bug behind it though. Is there a section in the Prisma spec that supports having DateTime as id
?
Besides that, I’ve been thinking about how to handle unique
constrains. I think we should focus on making sure that there are enough unique values that we can produce in the pool before even starting the test-utils
. For example, if you are trying to specify how to generate unique field for 100 people, but your function only packs 100 unique values, it might be extremely hard for test-utils
to find all the unique values by iterating over and over. Having only 50 unique values to choose from might be even bigger problem. I think we could solve that by accepting an array of unique fields instead of a function or a static value, and let people specify it that way. On the other hand, chance.js
(our mocking toolkit), implements a unique
function that we can use as a good default.
What do you think?
I am still unsure I understand the bug behind it though. Is there a section in the Prisma spec that supports having DateTime as
id
?
If databases do, Prisma needs to have a way to handle that.
What do you think?
I don't understand any of that - so I am assume it makes sense.
Fails for Joomla table:
https://github.com/prisma/database-schema-examples/blob/master/mysql/joomla/schema.sql#L137-L156
Introspected model:
This is most likely a test-utils bug as it is not reproducible directly with client when using the same call.
All seed logs: https://github.com/prisma/introspection-engine-output/blob/test_utils/test-utils/results/mysql_public_test_utils_joomla_stderr.log#L703