I am trying to write a query for a situation like "If you see value 10 and you do not see value 20 in the next 10 seconds trigger an alert" but have not been able to make the syntax work. According to this pull request this functionality was implemented over a year ago. My attempt at the query is:
define stream inStream(value int);
from every s1=inStream[value == 10]
-> not s2=inStream[value == 20] for 10 sec
select s2.value
insert into outStream
Looking at the grammar file in the Siddhi project this looks like it should be a valid query, however when I try and run it I get "Syntax error in SiddhiQL, no viable alternative at input". I am running this with siddhi-core 4.2.18. Is my syntax incorrect or do I have a different issue?
Found a solution to my issue at the tutorial site from the creator of the absence pattern PR. The issue was my syntax, the absence pattern's stream can not be named. So changing the query to
define stream inStream(value int);
from every s1=inStream[value == 10]
-> not inStream[value == 20] for 10 sec
select s1.value
insert into outStream
made it work perfectly.
Related
Am using Oracle 12.1 c when i run specific query ( i cant show for security reason , and because its un related); i get exception
ORA-00604: error occurred at recursive SQL
level 1 ORA-12899: value too large for column "SOME_SCHEMA"."PLAN_TABLE"."OBJECT_NAME"
(actual: 38, maximum: 30)
I cant make it work , i will try revert last changes i did because it was working before.
BTW i was doing Explain and doing index optimizations
Any idea why!
P.S i will keep trying
How i solved this:
When i was reverting and reviewing my last changes i was doing alters for adding indexes, and each time i try to run the query again to make sure it is working.
So when i reached a specific alter i noticed the name of the index is too long,
so even if the index was created successfully, but the explain plan for select
was failing not the select it self.
The solution:
I renamed the index to be shorter ( 30 maximum ) it worked
Change table/column/index names size in oracle 11g or 12c
Why are Oracle table/column/index names limited to 30 characters?
Using EXPLAIN PLAN Oracle websites docs
I have several counters in an application I am building, as am trying to get them to be dynamically created by the application as required.
For a simplistic example, if someone types a word into a script it should return the number of times that word has been entered previously. Here is an example of sql that may be executed if they typed the word example.
CREATE SEQUENCE IF NOT EXISTS example START WITH 1;
SELECT nextval('example')
This would return 1 the first time it ran, 2 the second time, etc.
The problem is when 2 people click the button at the same time.
First, please note that a lot more is happening in my application than just these statements, so the chances of them overlapping is much more significant than it would be if this was all that was happening.
1> BEGIN;
2> BEGIN;
1> CREATE SEQUENCE IF NOT EXISTS example START WITH 1;
2> CREATE SEQUENCE IF NOT EXISTS example START WITH 1; -- is blocked by previous statement
1> SELECT nextval('example') -- returns 1 to user.
1> COMMIT; -- unblocks second connection
2> ERROR: duplicate key value violates unique constraint
"pg_type_typname_nsp_index"
DETAIL: Key (typname, typnamespace)=(example, 109649) already exists.
I was under the impression that by using "IF NOT EXISTS", the statement should just be a no-op if it does exist, but it seems to have this race condition where that is not the case. I say race condition because if these two are not executed at the same time, it works as one would expect.
I have noticed that IF NOT EXISTS is fairly new to postgres, so maybe they haven't worked out all of the kinks yet?
EDIT:
The main reason we were considering doing things this way was to avoid excess locking. The thought being that if two people were to increment at the same time, using a sequence would mean that neither user should have to wait for the other (except, as in this example, for the initial creation of that sequence)
Sequences are part of the database schema. If you find yourself modifying the schema dynamically based on the data stored in the database, you are probably doing something wrong. This is especially true for sequences, which have special properties e.g. regarding their behavior with respect to transactions. Specifically, if you increment a sequence (with the help of nextval) in the middle of a transaction and then you rollback that transaction, the value of the sequence will not be rolled back. So most likely, this kind of behavior is something that you don't want with your data. In your example, imagine that a user tries to add word. This results in the corresponding sequence being incremented. Now imagine that the transaction does not complete for reason (e.g. maybe the computer crashes) and it gets rolled back. You would end up with the word not being added to the database but with the sequence being incremented.
For the particular example that you mentioned, there is an easy solution; create an ordinary table to store all the "sequences". Something like that would do it:
CREATE TABLE word_frequency (
word text NOT NULL UNIQUE,
frequency integer NOT NULL
);
Now I understand that this is just an example, but if this approach doesn't work for your actual use case, let us know and we can adjust it to your needs.
Edit: Here's how you the above solution works. If a new word is added, run the following query ("UPSERT" syntax in postgres 9.5+ only):
INSERT INTO word_frequency(word,frequency)
VALUES ('foo',1)
ON CONFLICT (word)
DO UPDATE
SET frequency = word_frequency.frequency + excluded.frequency
RETURNING frequency;
This query will insert a new word in word_frequency with frequency 1, or if the word exists already it will increment the existing frequency by 1. Now what happens if two transaction try to do that at the same time? Consider the following scenario:
client 1 client 2
-------- --------
BEGIN
BEGIN
UPSERT ('foo',1)
UPSERT ('foo',1) <====
COMMIT
COMMIT
What will happen is that as soon as client 2 tries increment the frequency for foo (marked with the arrow above), that operation will block because the row was modified by a different transaction. When client 1 commits, client 2 will get unblocked and continue without any errors. This is exactly how we wanted it to work. Also note, that postgresql will use row-level locking to implement this behavior, so other insertions will not be blocked.
EDIT: The main reason we were considering doing things this way was to
avoid excess locking. The thought being that if two people were to
increment at the same time, using a sequence would mean that neither
user should have to wait for the other (except, as in this example,
for the initial creation of that sequence)
It sounds like you're optimizing for a problem that likely does not exist. Sure, if you have 100,000 simultaneous users that are only inserting rows (since a sequence will only be used then normally) there is the possibility of some contention with the sequence but realistically there will be other bottle necks long before the sequence gets in the way.
I'd advise you to first prove that the sequence is an issue. With a proper database design (which dynamic DDL is not) the sequence will not be the bottle neck.
As a reference, DDL is not transaction safe in most databases.
My code
var numberOfStudents = _context.Student.Count();
In the database , about 4.000.000 records.
I tried
var numberOfStudents = _context.Student.Count();
but "Timeout expired" error still occur.
I setted command timout to 5 mins. But this error still occur.
Please run this query and tell me how long does it take to execute
Select Count(*) from Students
Also, please post your table structure, including all the Indices.
I assume adding a suitable index on the table will solve the problem, but I need more information. Most probably, adding any NonClustered Index will make this fast. Please see SQL count(*) performance.
variations of this question has been asked on SO and on many blogs but none offers a straight-forward answer. I hope there is one.
I am updating PostgreSQL 9.0 (from CodeIgniter, PHP framework):
$sql_order = "UPDATE meters SET billed=true";
$query = $this->db->query($sql_order);
I simply need a count of rows that were affected by the update, but there seems to be no way to do this with PostgreSQL. The query is now returning a boolean - true.
The manual and web talk refer to the RETURNING syntax, to GET DIAGNOSTICS, and to a default return type from UPDATE. I haven't been able to get any of these to work.
Is there a straightforward way of getting rows affect count without having to embed this simple operation into a procedure or transaction.
In Java I would have used the following:
Statement stmt = connection.createStatement();
int rowsAffected = stmt.executeUpdate("UPDATE ...");
In PHP I believe pg_affected_rows is the way. And in your particular case $this->db->affected_rows()
Here’s the scenario:
You load a page, which renders based on the data in the database (call these the “assumptions”)
Someone changes the assumptions
You submit your page
ERROR!
The general pattern to solve this problem is this (right?):
In your save proc, inside a begin and commit transaction, you validate your assumptions first. If any of them changed, you should return a graceful error message, something like an XML list of the ID’s you had problems with, that you handle in the page rather than let it be handled by the default error handling infrastructure.
So my question is what is the best way to do that?
Return the xml list and an error flag in out parameters that are unset and 0 if it completes correctly?
Use an out parameter to return an error status, and the result of the proc be either the error list or the valid results of the proc?
Something else? (I should note that raiseerror would cause the proc to be in error, and get picked up by the default error handling code)
Update: I would like to return a maniplatable list of IDs that failed (I plan to highlight those cells in the application). I could return them in CSV format in RAISEERROR, but that seems dirty.
I agree - I like RAISEERROR:
-- Validate #whatever
IF #whatever >= '5'
BEGIN
RAISERROR ('Invalid value for #whatever - expected a value less than 5, but received %s.', 10, 1, #whatever)
RETURN 50000
END;
Use the RAISERROR function with the appropriate severity and/or wait level. If you use a low severity this does not necessarily cause an exception, as you contend, and with .Net at least its pretty simple to retrieve these messages. The only downside is that with the StoredProcedure command type in .Net messages are only pumped in groups of 50.
Stored procedures can return multiple result sets. Based on your update, you could also insert errored ids into a temporary table, and then at the end of your procedure select the records from that table as an additional result set you can look at.
I would do an output parameter with a message, the return will already have something which is not 0 if there is an error
also be careful with doomed transaction and check with xact_error, see Use XACT_ABORT to roll back non trapable error transactions