-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
INSERT INTO silently fails if targeting a stream not created with CSAS #2146
Comments
@rmoff - you're basically saying that INSERT INTO doesn't work at all? In your second example of a working query, you don't issue an INSERT INTO at all - only a CSAS |
|
INSERT INTO should work the same, whether the sink was created via a CSAS or a CS statement. |
This is a bug in how we choose the kafka topic name to write into. Each topic in the metastore has 2 names, a "ksql name", and a "kafka name". The "kafka name" is the name of the topic in Kafka. The "KSQL name" is an internal name for the topic (that happens to be a case-insensitive version of the "kafka name"). For sources created with CS, the KSQL name for the topic backing the data source uses upper-case. For sources created with CSAS, it's lower-case. When telling streams which topic to write into, KSQL is using the KSQL name. So if the sink was created with CS (as with insert-into), we use the wrong topic name. The fix is to use the kafka name. @rmoff - what happens when you run |
This was a regression in 5.1 which is fixed by #2149 . |
Raised by user here: https://stackoverflow.com/questions/53226781/ksql-insert-into-a-stream-yields-no-data
tl;dr unless the target stream for
INSERT INTO
is a stream created by CSAS (i.e. it's instead created against an existing topic), then despite saying it's running and showing as processing messages, none are written to the target stream/topic.For
INSERT INTO
to work it needs to be targetting a stream created withCREATE STREAM target AS SELECT
("CSAS"), NOT a stream simply registered against an existing topic. This is a bug because it silently fails and does not tell the user (and even says that it has processed messages).Let's work it through. Here I'm using this docker-compose for a test setup.
Populate some dummy data:
Register the source topic with KSQL:
Query the stream:
Create the target topic:
And then creating the stream against this topic:
Note that it says
Stream created
, rather thanStream created and running
Now let's run the
INSERT INTO
:The
DESCRIBE EXTENDED
output does indeed show, as you have seen, messages being processed:But the topic itself has no messages:
nor the KSQL Stream:
So the
INSERT INTO
command is designed to run against an existing CSAS/CTAS target stream, rather than a source STREAM registered against an existing topic.Let's try it that way instead. First, we need to drop the existing stream definition, and to do that also terminate the
INSERT INTO
query:Now create the target stream:
Note that in creating the stream it is also
running
(vs before it was justcreated
). Now query the stream:and check the underlying topic too:
So, you have hit a bug in KSQL, but one that fortunately can be avoided by using a simpler KSQL syntax entirely, combining your
CREATE STREAM
andINSERT INTO
queries into one.The text was updated successfully, but these errors were encountered: