{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":495863734,"defaultBranch":"main","name":"readyset","ownerLogin":"readysettech","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2022-05-24T14:39:20.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/71727599?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717709695.0","currentOid":""},"activityList":{"items":[{"before":"2079589fb133c5fcf5ac28241d0506e19e13d757","after":"29e7f1926490d6129194a51f05e20d69ca219976","ref":"refs/heads/I06b43400e29daae042afd0feb3d82a7fb9d48e29","pushedAt":"2024-06-06T21:59:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"adapter: Output indexes as string in EXPLAIN MATERIALIZATIONS\n\nMySQL does not support arrays, and this is just for informational\npurposes (i.e. it is unlikely anyone will be using these values\nprogrammatically), so let's keep things simple by having Postgres and\nMySQL match.\n\nFixes: REA-4324\nChange-Id: I06b43400e29daae042afd0feb3d82a7fb9d48e29","shortMessageHtmlLink":"adapter: Output indexes as string in EXPLAIN MATERIALIZATIONS"}},{"before":null,"after":"2079589fb133c5fcf5ac28241d0506e19e13d757","ref":"refs/heads/I06b43400e29daae042afd0feb3d82a7fb9d48e29","pushedAt":"2024-06-06T21:34:55.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"adapter: Output indexes as string in EXPLAIN MATERIALIZATIONS\n\nMySQL does not support arrays, and this is just for informational\npurposes (i.e. it is unlikely anyone will be using these values\nprogrammatically), so let's keep things simple by having Postgres and\nMySQL match.\n\nChange-Id: I06b43400e29daae042afd0feb3d82a7fb9d48e29","shortMessageHtmlLink":"adapter: Output indexes as string in EXPLAIN MATERIALIZATIONS"}},{"before":"5b2e88beb79f4a136282a79f9d340b7ed1a1397c","after":"2970cd232c4dfbdb3c2cdceeab80c6f81c17006a","ref":"refs/heads/I8fcc95af5057f534841c669b46e47bd774ceed58","pushedAt":"2024-06-06T21:02:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"controller: Reject unsupported MySQL storage engines\n\nSome storage engines are unsupported only because we require consistent\nsnapshots when first replicating a table, and not every storage engine\nhas the MVCC we currently rely on for that consistency. In the future,\nwe could remove this exception by wrapping our snapshots with table\nlocks for non-transactional storage engines. This could be a bad user\nexperience if someone is connecting Readyset to a live cluster causing\nit to, perhaps unwittingly, snapshot a large legacy MyISAM table and\npossibly lock up part of their workload. We could add an option to allow\nlocking tables and default to rejection. Either way, supporting locking\nwould add some complexity to the snapshot code that does not seem\nworthwhile absent explicit demand for this functionality. We already\nlock tables to read their binlog position, but we would then have to\nconditionally move the unlock to after the snapshot finishes. I believe\nthis would require making the `TableDumper` (or the `Future` that runs\nit) conditionally take ownership over the connection that locked the\ntable, but only if we have the locking option enabled and are\nsnapshotting a table that requires it.\n\nArguably, this decision should be up to the replicator, not the\ncontroller: as long as it can snapshot and forward rows for the table,\nthe server doesn't care how the table is persisted (or not), so we\nshould let the code in charge of replicating decide whether it can\nreplicate. However, the controller (and specifically `SqlIncorporator`)\nis already where we parse, inspect, and make decisions about DDL; this\ncodepath is common to both initial snapshotting and coming across DDL\nduring replication; and saying \"unsupported\" here already does what we\nwant with regard to adding the table to the `TableFilter`. It does not\nseem worth duplicating the parsing and discrimination in two places in\nthe replicator.\n\nFixes: REA-4328\nChange-Id: I8fcc95af5057f534841c669b46e47bd774ceed58","shortMessageHtmlLink":"controller: Reject unsupported MySQL storage engines"}},{"before":"3a78b8253d47e87e483048328725f7da0a0f21af","after":"dd6c8b3f49d7d7ff20cf23479436c3724db063a9","ref":"refs/heads/main","pushedAt":"2024-06-06T21:01:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"dataflow: Correct return type for SUM in Postgres\n\nWe were returning what MySQL was expecting, so this is just doing what\nPostgres expects when appropriate.\n\nThis patch makes `readyset_dataflow` aware of `Dialect` in a way it\nwasn't before, which although limited to this operator constructor may\nbe undesirable; but the alternative of having a secondary function for\ndetermining the type which `mir_to_flow` would have to call separately\nwas equally if not more unwieldy.\n\nAddresses: REA-4283\nChange-Id: I2e7532b038f0be0e05347bd3f2f861d996221a25\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7535\nTested-by: Buildkite CI\nReviewed-by: Jason Brown <jason.b@readyset.io>","shortMessageHtmlLink":"dataflow: Correct return type for SUM in Postgres"}},{"before":"401a3d71a092c8c7d6c60aadce00f188f5f60230","after":"3a78b8253d47e87e483048328725f7da0a0f21af","ref":"refs/heads/I97831ebc9116aedfe5023154ba26713a725f03c2","pushedAt":"2024-06-06T18:34:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"logictests: Set schema search path when replicating\n\nWhen the real adapter runs, it connects to the upstream to get the\ncurrent schema search path. We don't do that in logictests, but still\nwant to be able to run manually against the default replication targets,\nso just hardcode them when running with replication.\n\nAddresses: REA-4283\nChange-Id: I97831ebc9116aedfe5023154ba26713a725f03c2\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7549\nReviewed-by: Marcelo Altmann <marcelo@readyset.io>\nTested-by: Buildkite CI","shortMessageHtmlLink":"logictests: Set schema search path when replicating"}},{"before":"6f2474c76a4be173419cf3ae232be936fd1cb58f","after":"b953a076fb805453945425f2629cf2fd0a142ed0","ref":"refs/heads/Idc927cc59cb200b9373d0219f87dc4474ff103d0","pushedAt":"2024-06-05T22:57:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"wip: Use replication during nightly logictests\n\nAddresss: REA-4283\nChange-Id: Idc927cc59cb200b9373d0219f87dc4474ff103d0","shortMessageHtmlLink":"wip: Use replication during nightly logictests"}},{"before":"3fced1a9b20b6764cada0b1f04035a43e7b5a61a","after":"8f734bc0363f4c480495bb5473fabde25294989e","ref":"refs/heads/I2e7532b038f0be0e05347bd3f2f861d996221a25","pushedAt":"2024-06-05T22:57:52.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"dataflow: Correct return type for SUM in Postgres\n\nWe were returning what MySQL was expecting, so this is just doing what\nPostgres expects when appropriate.\n\nThis patch makes `readyset_dataflow` aware of `Dialect` in a way it\nwasn't before, which although limited to this operator constructor may\nbe undesirable; but the alternative of having a secondary function for\ndetermining the type which `mir_to_flow` would have to call separately\nwas equally if not more unwieldy.\n\nAddresses: REA-4283\nChange-Id: I2e7532b038f0be0e05347bd3f2f861d996221a25","shortMessageHtmlLink":"dataflow: Correct return type for SUM in Postgres"}},{"before":"43216036e72e402f647526293aa426145a489779","after":"3a78b8253d47e87e483048328725f7da0a0f21af","ref":"refs/heads/main","pushedAt":"2024-06-05T21:27:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"logictests: Set schema search path when replicating\n\nWhen the real adapter runs, it connects to the upstream to get the\ncurrent schema search path. We don't do that in logictests, but still\nwant to be able to run manually against the default replication targets,\nso just hardcode them when running with replication.\n\nAddresses: REA-4283\nChange-Id: I97831ebc9116aedfe5023154ba26713a725f03c2\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7549\nReviewed-by: Marcelo Altmann <marcelo@readyset.io>\nTested-by: Buildkite CI","shortMessageHtmlLink":"logictests: Set schema search path when replicating"}},{"before":"66806921a77e4dde886acb046529496dd279f600","after":"43216036e72e402f647526293aa426145a489779","ref":"refs/heads/main","pushedAt":"2024-06-05T21:23:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"mysql: Clear prepared statement schema cache\n\nIf we closed or deallocated a statement, and later prepared a different\nstatement with the same ID, we would reuse the previously cached\nresultset schema when encoding results which could lead to errors. Be\nconsistent about clearing the schema cache by removing entries from it\nwhen explicitly closed/deallocated and before adding new entries.\n\nAddresses: REA-4283\nChange-Id: Iaa6dcf2521246ced8f7c87547505743044c6b54c\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7542\nTested-by: Buildkite CI\nReviewed-by: Jason Brown <jason.b@readyset.io>\nReviewed-by: Marcelo Altmann <marcelo@readyset.io>","shortMessageHtmlLink":"mysql: Clear prepared statement schema cache"}},{"before":"0fb1f464c2e041fbd36b066d71b6d1803c72d736","after":"66806921a77e4dde886acb046529496dd279f600","ref":"refs/heads/Ibb436b99b46500f940efe79d06d86494bfc4bf30","pushedAt":"2024-06-05T21:15:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"replicators: add collation support for CHAR and BINARY columns\n\nThis commits adds proper collation support for CHAR and BINARY columns\nin MySQL.\nCHAR columns should be right padded with spaces to the column length\nwhen storing them and BINARY should right pad zeros.\n\nThis commit fixes the issue at snapshot - During snapshot we do a\nlogical dump of data. MySQL removes padding spaces from CHAR columns\nwhen retrieving them. So, we need to take the column collation into\nconsideration when storing them. One gotcha is with ENUM/SET columns,\nthey are retrieved as Strings(MYSQL_TYPE_STRING), but we should not\npad them.\nDuring CDC, we need to retrieve proper\nmetadata from TME in order to validate if padding is necessary or not.\n\nThis commit also fixes an issue when storing BINARY columns. We were\nstoring them as TinyText/Text if the binary representation of the\ncolumns was a valid UTF-8 string. This is not correct. We should store\nthem as ByteArray.\n\nTest cases were written taking into consideration a mix of characters\nfrom different bytes, like mixing ASCII and UTF-8 characters from\n2nd and 3rd bytes.\n\nNote: MySQL uses the terminology of charset and collation interchangeably.\nIn the end everything is stored as collation ID, which can be used to\ndetermine the charset and collation.\n\nRef: REA-4366\nRef: REA-4383\nCloses: #1247 #1259\n\nRelease-Note-Core: Added collation support for storing CHAR and BINARY\n   columns in MySQL using the correct padding. This fixes an issue when\n   looking up CHAR/BINARY columns with values that do not match the\n   column length.\n\nChange-Id: Ibb436b99b46500f940efe79d06d86494bfc4bf30\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7510\nTested-by: Buildkite CI\nReviewed-by: Michael Zink <michael.z@readyset.io>","shortMessageHtmlLink":"replicators: add collation support for CHAR and BINARY columns"}},{"before":"32f045a48b20f2e69a964dce6f9eb1ab9ac3ee70","after":"66806921a77e4dde886acb046529496dd279f600","ref":"refs/heads/main","pushedAt":"2024-06-05T21:11:19.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"replicators: add collation support for CHAR and BINARY columns\n\nThis commits adds proper collation support for CHAR and BINARY columns\nin MySQL.\nCHAR columns should be right padded with spaces to the column length\nwhen storing them and BINARY should right pad zeros.\n\nThis commit fixes the issue at snapshot - During snapshot we do a\nlogical dump of data. MySQL removes padding spaces from CHAR columns\nwhen retrieving them. So, we need to take the column collation into\nconsideration when storing them. One gotcha is with ENUM/SET columns,\nthey are retrieved as Strings(MYSQL_TYPE_STRING), but we should not\npad them.\nDuring CDC, we need to retrieve proper\nmetadata from TME in order to validate if padding is necessary or not.\n\nThis commit also fixes an issue when storing BINARY columns. We were\nstoring them as TinyText/Text if the binary representation of the\ncolumns was a valid UTF-8 string. This is not correct. We should store\nthem as ByteArray.\n\nTest cases were written taking into consideration a mix of characters\nfrom different bytes, like mixing ASCII and UTF-8 characters from\n2nd and 3rd bytes.\n\nNote: MySQL uses the terminology of charset and collation interchangeably.\nIn the end everything is stored as collation ID, which can be used to\ndetermine the charset and collation.\n\nRef: REA-4366\nRef: REA-4383\nCloses: #1247 #1259\n\nRelease-Note-Core: Added collation support for storing CHAR and BINARY\n   columns in MySQL using the correct padding. This fixes an issue when\n   looking up CHAR/BINARY columns with values that do not match the\n   column length.\n\nChange-Id: Ibb436b99b46500f940efe79d06d86494bfc4bf30\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7510\nTested-by: Buildkite CI\nReviewed-by: Michael Zink <michael.z@readyset.io>","shortMessageHtmlLink":"replicators: add collation support for CHAR and BINARY columns"}},{"before":"cec09264e28eaad617ed7ecf05988692c8d76170","after":"401a3d71a092c8c7d6c60aadce00f188f5f60230","ref":"refs/heads/I97831ebc9116aedfe5023154ba26713a725f03c2","pushedAt":"2024-06-05T17:25:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"logictests: Set schema search path when replicating\n\nWhen the real adapter runs, it connects to the upstream to get the\ncurrent schema search path. We don't do that in logictests, but still\nwant to be able to run manually against the default replication targets,\nso just hardcode them when running with replication.\n\nAddresses: REA-4283\nChange-Id: I97831ebc9116aedfe5023154ba26713a725f03c2","shortMessageHtmlLink":"logictests: Set schema search path when replicating"}},{"before":null,"after":"cec09264e28eaad617ed7ecf05988692c8d76170","ref":"refs/heads/I97831ebc9116aedfe5023154ba26713a725f03c2","pushedAt":"2024-06-05T17:25:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"logictests: Set schema search path when replicating\n\nWhen the real adapter runs, it connects to the upstream to get the\ncurrent schema search path. We don't do that in logictests, but still\nwant to be able to run manually against the default replication targets,\nso just hardcode them when running with replication. # Please enter the\ncommit message for your changes. Lines starting\n\nAddresses: REA-4283\nChange-Id: I97831ebc9116aedfe5023154ba26713a725f03c2","shortMessageHtmlLink":"logictests: Set schema search path when replicating"}},{"before":"d5d813a8bd5d4e9c30dd225ee8219e149cda1f45","after":"32f045a48b20f2e69a964dce6f9eb1ab9ac3ee70","ref":"refs/heads/I1632d395c8388963f7567e8b8d74fcda1d8886a4","pushedAt":"2024-06-04T21:29:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"nom-sql: Parse CREATE DATABASE statement for MySQL\n\n- This ticket is for syntactic support of CREATE DATABASE statement,\nwithout processing it. This allows for avoiding a confusing error\nmessage as such statement is issued.\n\nFixes: REA-4244\nChange-Id: I1632d395c8388963f7567e8b8d74fcda1d8886a4\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7520\nTested-by: Buildkite CI\nReviewed-by: Ethan Donowitz <ethan@readyset.io>","shortMessageHtmlLink":"nom-sql: Parse CREATE DATABASE statement for MySQL"}},{"before":"9493ea26e6253f9f7463653152ede037db735770","after":"0fb1f464c2e041fbd36b066d71b6d1803c72d736","ref":"refs/heads/Ibb436b99b46500f940efe79d06d86494bfc4bf30","pushedAt":"2024-06-04T18:03:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"replicators: add collation support for CHAR and BINARY columns\n\nThis commits adds proper collation support for CHAR and BINARY columns\nin MySQL.\nCHAR columns should be right padded with spaces to the column length\nwhen storing them and BINARY should right pad zeros.\n\nThis commit fixes the issue at snapshot - During snapshot we do a\nlogical dump of data. MySQL removes padding spaces from CHAR columns\nwhen retrieving them. So, we need to take the column collation into\nconsideration when storing them. One gotcha is with ENUM/SET columns,\nthey are retrieved as Strings(MYSQL_TYPE_STRING), but we should not\npad them.\nDuring CDC, we need to retrieve proper\nmetadata from TME in order to validate if padding is necessary or not.\n\nThis commit also fixes an issue when storing BINARY columns. We were\nstoring them as TinyText/Text if the binary representation of the\ncolumns was a valid UTF-8 string. This is not correct. We should store\nthem as ByteArray.\n\nTest cases were written taking into consideration a mix of characters\nfrom different bytes, like mixing ASCII and UTF-8 characters from\n2nd and 3rd bytes.\n\nNote: MySQL uses the terminology of charset and collation interchangeably.\nIn the end everything is stored as collation ID, which can be used to\ndetermine the charset and collation.\n\nRef: REA-4366\nRef: REA-4383\nCloses: #1247 #1259\n\nRelease-Note-Core: Added collation support for storing CHAR and BINARY\n   columns in MySQL using the correct padding. This fixes an issue when\n   looking up CHAR/BINARY columns with values that do not match the\n   column length.\n\nChange-Id: Ibb436b99b46500f940efe79d06d86494bfc4bf30","shortMessageHtmlLink":"replicators: add collation support for CHAR and BINARY columns"}},{"before":"c82d7e3b8dbc340b91edd1924326304fba47811a","after":"32f045a48b20f2e69a964dce6f9eb1ab9ac3ee70","ref":"refs/heads/main","pushedAt":"2024-06-04T17:45:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"nom-sql: Parse CREATE DATABASE statement for MySQL\n\n- This ticket is for syntactic support of CREATE DATABASE statement,\nwithout processing it. This allows for avoiding a confusing error\nmessage as such statement is issued.\n\nFixes: REA-4244\nChange-Id: I1632d395c8388963f7567e8b8d74fcda1d8886a4\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7520\nTested-by: Buildkite CI\nReviewed-by: Ethan Donowitz <ethan@readyset.io>","shortMessageHtmlLink":"nom-sql: Parse CREATE DATABASE statement for MySQL"}},{"before":"37f9d763b760e8caaa3af67411fe25fc9a2b9d70","after":"d5d813a8bd5d4e9c30dd225ee8219e149cda1f45","ref":"refs/heads/I1632d395c8388963f7567e8b8d74fcda1d8886a4","pushedAt":"2024-06-04T17:00:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"nom-sql: Parse CREATE DATABASE statement for MySQL\n\n- This ticket is for syntactic support of CREATE DATABASE statement,\nwithout processing it. This allows for avoiding a confusing error\nmessage as such statement is issued.\n\nFixes: REA-4244\nChange-Id: I1632d395c8388963f7567e8b8d74fcda1d8886a4","shortMessageHtmlLink":"nom-sql: Parse CREATE DATABASE statement for MySQL"}},{"before":"01c436f36c9cc250c3b1288ee12d188b44e0ee0b","after":"37f9d763b760e8caaa3af67411fe25fc9a2b9d70","ref":"refs/heads/I1632d395c8388963f7567e8b8d74fcda1d8886a4","pushedAt":"2024-06-04T15:32:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"nom-sql: Parse CREATE DATABASE statement for MySQL\n\n- This ticket is for syntactic support of CREATE DATABASE statement,\nwithout processing it. This allows for avoiding a confusing error\nmessage as such statement is issued.\n\nFixes: REA-4244\nChange-Id: I1632d395c8388963f7567e8b8d74fcda1d8886a4","shortMessageHtmlLink":"nom-sql: Parse CREATE DATABASE statement for MySQL"}},{"before":"b0fea8892b6204f7a41874ebe047f656a4ff6bce","after":"6f2474c76a4be173419cf3ae232be936fd1cb58f","ref":"refs/heads/Idc927cc59cb200b9373d0219f87dc4474ff103d0","pushedAt":"2024-06-03T22:48:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"wip: Use replication during nightly logictests\n\nAddresss: REA-4283\nChange-Id: Idc927cc59cb200b9373d0219f87dc4474ff103d0","shortMessageHtmlLink":"wip: Use replication during nightly logictests"}},{"before":"05b9e00d528b0ff83ff4900c8af0236b40ea918b","after":"3fced1a9b20b6764cada0b1f04035a43e7b5a61a","ref":"refs/heads/I2e7532b038f0be0e05347bd3f2f861d996221a25","pushedAt":"2024-06-03T22:48:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"dataflow: Correct return type for SUM in Postgres\n\nWe were returning what MySQL was expecting, so this is just doing what\nPostgres expects when appropriate.\n\nThis patch makes `readyset_dataflow` aware of `Dialect` in a way it\nwasn't before, which although limited to this operator constructor may\nbe undesirable; but the alternative of having a secondary function for\ndetermining the type which `mir_to_flow` would have to call separately\nwas equally if not more unwieldy.\n\nAddresses: REA-4283\nChange-Id: I2e7532b038f0be0e05347bd3f2f861d996221a25","shortMessageHtmlLink":"dataflow: Correct return type for SUM in Postgres"}},{"before":"f1d59f227181779ed22a18a0a598b86beb012b9e","after":"f57d89e50ca890795822eee17667e420e2b84e04","ref":"refs/heads/Iaa6dcf2521246ced8f7c87547505743044c6b54c","pushedAt":"2024-06-03T22:48:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"mysql: Clear prepared statement schema cache\n\nIf we closed or deallocated a statement, and later prepared a different\nstatement with the same ID, we would reuse the previously cached\nresultset schema when encoding results which could lead to errors. Be\nconsistent about clearing the schema cache by removing entries from it\nwhen explicitly closed/deallocated and before adding new entries.\n\nAddresses: REA-4283\nChange-Id: Iaa6dcf2521246ced8f7c87547505743044c6b54c","shortMessageHtmlLink":"mysql: Clear prepared statement schema cache"}},{"before":null,"after":"f1d59f227181779ed22a18a0a598b86beb012b9e","ref":"refs/heads/Iaa6dcf2521246ced8f7c87547505743044c6b54c","pushedAt":"2024-06-03T22:37:43.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"mysql: Clear prepared statement schema cache\n\nIf we closed or deallocated a statement, and later prepared a different\nstatement with the same ID, we would reuse the previously cached\nresultset schema when encoding results which could lead to errors. Be\nconsistent about clearing the schema cache by removing entries from it\nwhen explicitly closed/deallocated and before adding new entries.\n\nChange-Id: Iaa6dcf2521246ced8f7c87547505743044c6b54c","shortMessageHtmlLink":"mysql: Clear prepared statement schema cache"}},{"before":"e4905865d9aa239dfc8f925d191315de9adccafd","after":"b0fea8892b6204f7a41874ebe047f656a4ff6bce","ref":"refs/heads/Idc927cc59cb200b9373d0219f87dc4474ff103d0","pushedAt":"2024-06-03T22:37:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"wip: Use replication during nightly logictests\n\nChange-Id: Idc927cc59cb200b9373d0219f87dc4474ff103d0","shortMessageHtmlLink":"wip: Use replication during nightly logictests"}},{"before":"5021d0843f86d5a175ffd9ce59384488e0f3bc03","after":"05b9e00d528b0ff83ff4900c8af0236b40ea918b","ref":"refs/heads/I2e7532b038f0be0e05347bd3f2f861d996221a25","pushedAt":"2024-06-03T22:37:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"dataflow: Correct return type for SUM in Postgres\n\nChange-Id: I2e7532b038f0be0e05347bd3f2f861d996221a25","shortMessageHtmlLink":"dataflow: Correct return type for SUM in Postgres"}},{"before":"dc2a42aecca148a148f1c114bcec0d3c3aa70459","after":"01c436f36c9cc250c3b1288ee12d188b44e0ee0b","ref":"refs/heads/I1632d395c8388963f7567e8b8d74fcda1d8886a4","pushedAt":"2024-06-03T22:12:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"nom-sql: Parse CREATE DATABASE statement for MySQL\n\n- This ticket is for syntactic support of CREATE DATABASE statement,\nwithout processing it. This allows for avoiding a confusing error\nmessage as such statement is issued.\n\nFixes: REA-4244\nChange-Id: I1632d395c8388963f7567e8b8d74fcda1d8886a4","shortMessageHtmlLink":"nom-sql: Parse CREATE DATABASE statement for MySQL"}},{"before":"998103c5f7bbcf248cec304a4ba2d3d7acd2e203","after":"5b2e88beb79f4a136282a79f9d340b7ed1a1397c","ref":"refs/heads/I8fcc95af5057f534841c669b46e47bd774ceed58","pushedAt":"2024-06-03T20:18:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"controller: Reject unsupported MySQL storage engines\n\nSome storage engines are unsupported only because we require consistent\nsnapshots when first replicating a table, and not every storage engine\nhas the MVCC we currently rely on for that consistency. In the future,\nwe could remove this exception by wrapping our snapshots with table\nlocks for non-transactional storage engines. This could be a bad user\nexperience if someone is connecting Readyset to a live cluster causing\nit to, perhaps unwittingly, snapshot a large legacy MyISAM table and\npossibly lock up part of their workload. We could add an option to allow\nlocking tables and default to rejection. Either way, supporting locking\nwould add some complexity to the snapshot code that does not seem\nworthwhile absent explicit demand for this functionality. We already\nlock tables to read their binlog position, but we would then have to\nconditionally move the unlock to after the snapshot finishes. I believe\nthis would require making the `TableDumper` (or the `Future` that runs\nit) conditionally take ownership over the connection that locked the\ntable, but only if we have the locking option enabled and are\nsnapshotting a table that requires it.\n\nArguably, this decision should be up to the replicator, not the\ncontroller: as long as it can snapshot and forward rows for the table,\nthe server doesn't care how the table is persisted (or not), so we\nshould let the code in charge of replicating decide whether it can\nreplicate. However, the controller (and specifically `SqlIncorporator`)\nis already where we parse, inspect, and make decisions about DDL; this\ncodepath is common to both initial snapshotting and coming across DDL\nduring replication; and saying \"unsupported\" here already does what we\nwant with regard to adding the table to the `TableFilter`. It does not\nseem worth duplicating the parsing and discrimination in two places in\nthe replicator.\n\nFixes: REA-4328\nChange-Id: I8fcc95af5057f534841c669b46e47bd774ceed58","shortMessageHtmlLink":"controller: Reject unsupported MySQL storage engines"}},{"before":"531da4eba72edc91a7696d9d63845ecd08340cc7","after":"c82d7e3b8dbc340b91edd1924326304fba47811a","ref":"refs/heads/I56ea0995b899ce657b47bb42c6d2bef219db2516","pushedAt":"2024-06-03T15:58:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"treewide: Update Rust toolchain to 2024-05-02\n\nThis commit updates the Rust toolchain being used in both public/ and\ncrates/ to nightly 2024-05-02, which corresponds with the stable release\nof 1.78 on the same date.\n\nChange-Id: I56ea0995b899ce657b47bb42c6d2bef219db2516\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7439\nTested-by: Buildkite CI\nReviewed-by: Jason Brown <jason.b@readyset.io>","shortMessageHtmlLink":"treewide: Update Rust toolchain to 2024-05-02"}},{"before":"a4fee546b3beabce1741700a3f7ba93883e16c18","after":"c82d7e3b8dbc340b91edd1924326304fba47811a","ref":"refs/heads/main","pushedAt":"2024-06-03T14:36:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"treewide: Update Rust toolchain to 2024-05-02\n\nThis commit updates the Rust toolchain being used in both public/ and\ncrates/ to nightly 2024-05-02, which corresponds with the stable release\nof 1.78 on the same date.\n\nChange-Id: I56ea0995b899ce657b47bb42c6d2bef219db2516\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7439\nTested-by: Buildkite CI\nReviewed-by: Jason Brown <jason.b@readyset.io>","shortMessageHtmlLink":"treewide: Update Rust toolchain to 2024-05-02"}},{"before":"4b1a4dbb948aeb856a564e8ac8716d57ef3b363d","after":"a4fee546b3beabce1741700a3f7ba93883e16c18","ref":"refs/heads/main","pushedAt":"2024-06-03T14:33:15.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"build: Update cargo-deny version\n\nThis commit updates the cargo-deny version we use from 0.13.17 to\n0.14.23.\n\nChange-Id: I46039b68fa1f8fa02e08b5789a1151ca77314b35\nReviewed-on: https://gerrit.readyset.name/c/readyset/+/7448\nTested-by: Buildkite CI\nReviewed-by: Jason Brown <jason.b@readyset.io>","shortMessageHtmlLink":"build: Update cargo-deny version"}},{"before":"ee1a20e3ec5b6867fa660283994fad70a33937c7","after":"9493ea26e6253f9f7463653152ede037db735770","ref":"refs/heads/Ibb436b99b46500f940efe79d06d86494bfc4bf30","pushedAt":"2024-06-03T13:42:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"readysetbot","name":null,"path":"/readysetbot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/75456260?s=80&v=4"},"commit":{"message":"replicators: add collation support for CHAR and BINARY columns\n\nThis commits adds proper collation support for CHAR and BINARY columns\nin MySQL.\nCHAR columns should be right padded with spaces to the column length\nwhen storing them and BINARY should right pad zeros.\n\nThis commit fixes the issue at snapshot - During snapshot we do a\nlogical dump of data. MySQL removes padding spaces from CHAR columns\nwhen retrieving them. So, we need to take the column collation into\nconsideration when storing them. One gotcha is with ENUM/SET columns,\nthey are retrieved as Strings(MYSQL_TYPE_STRING), but we should not\npad them.\nDuring CDC, we need to retrieve proper\nmetadata from TME in order to validate if padding is necessary or not.\n\nThis commit also fixes an issue when storing BINARY columns. We were\nstoring them as TinyText/Text if the binary representation of the\ncolumns was a valid UTF-8 string. This is not correct. We should store\nthem as ByteArray.\n\nTest cases were written taking into consideration a mix of characters\nfrom different bytes, like mixing ASCII and UTF-8 characters from\n2nd and 3rd bytes.\n\nNote: MySQL uses the terminology of charset and collation interchangeably.\nIn the end everything is stored as collation ID, which can be used to\ndetermine the charset and collation.\n\nRef: REA-4366\nRef: REA-4383\nCloses: #1247 #1259\n\nRelease-Note-Core: Added collation support for storing CHAR and BINARY\n   columns in MySQL using the correct padding. This fixes an issue when\n   looking up CHAR/BINARY columns with values that do not match the\n   column length.\n\nChange-Id: Ibb436b99b46500f940efe79d06d86494bfc4bf30","shortMessageHtmlLink":"replicators: add collation support for CHAR and BINARY columns"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEXqcQ9AA","startCursor":null,"endCursor":null}},"title":"Activity · readysettech/readyset"}