Can you create functions in SQLite like you can in MSSQL?
If so, how? What is the syntax?
Thanks
SQLite does not have a stored function/stored procedure language. So CREATE FUNCTION does not work. What you can do though is map functions from a c library to SQL functions (user-defined functions). To do that, use SQLite's C API (see: http://www.sqlite.org/c3ref/create_function.html)
If you're not using the C API, your wrapper API may define something that allows you access to this feature, see for example:
PHP sqlite_create_function() (http://www.php.net/manual/en/function.sqlite-create-function.php)
Python sqlite3.create_function() (http://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.create_function)
Perl $dbh->sqlite_create_function($name,$argc,$code_ref,$flags) (https://metacpan.org/pod/DBD::SQLite#$dbh-%3Esqlite_create_function(-$name,-$argc,-$code_ref,-$flags-))
This could be useful to many: in SQLiteStudio it is possible to define new functions and collations easily from interface through a sql built-in plugin for example.
https://github.com/pawelsalawa/sqlitestudio/wiki/Official_plugins#sql-built-in
Through the function editor.
You can write arbitrary functions in SQL with the define extension:
-- define a function to sum the numbers 1..n
select define('sumn', ':n * (:n + 1) / 2');
-- use it as a regular function
select sumn(3);
6
select sumn(5);
15
Related
The documentation is not clear about how to use the merge operation while using rocksdb-jni, and I am not familiar with C++ API, how could I define an merge operator?
You can't define new merge operators in java. They need to be implemented in C++ and then compiled and brought in Java
Eg how to use the built in uint64add operator val options = Options().setMergeOperator(UInt64AddOperator())
and then you can use rocksDB.merge(keyByteArray, longValueByteArray)
I've got many questions :)
I've started to use Cosmos DB (SQL API). Loving it!
But I'm struggling to discover the best way of building and managing code. I'm using Visual Studio.
Here's some code, and I'll base my questions on these 4 javascript functions:
function createYayBase(something) {
// UDF
return {
pk: "Yay",
id: "Ptr=" + something
};
}
function createYayDoc(whatever, something) {
// UDF
var o = createYayBase(something);
o.Message = whatever;
return o;
}
function validateYayDoc(doc) {
// UDF
if (doc.pk !== "Yay") { throw new Error("non-Yay! :("); }
}
function processYay(val) {
// stored procedure
var doc = CreateYayDoc(val, "Rec");
validateYayDoc(doc);
...createDocument(selflink, doc, ...);
}
These 4 functions are in 4 different .js files in my solution. I would deploy the first 3 as their own user-defined function in my collection. The last, I would deploy as a stored procedure.
My app would execute the "processYay" stored procedure to do some operations. The UDFs are supportive.
Questions:
Can I call a UDF from a stored procedure directly, similar to how I've done it above in "processYay"? Or are they only accessible as part of a query?
Can I call a UDF from another UDF, as I did inside "createYayDoc"?
Can a UDF 'throw' or is that considered a side effect in this case?
If the answers are "nope", "nope" and "nope", there seems to be another solution: Define the functions inside the stored procedure itself. It would work perfectly like this:
function processYay(val) {
// stored procedure
function createYayBase(something) { ... }
function createYayDoc(whatever, something) { ... }
function validateYayDoc(val) { ... }
var doc = CreateYayDoc(val, "Rec");
validateYayDoc(doc);
...createDocument(selflink, doc, ...);
}
But then...
How can I reuse code?
My javascript sits inside a .NET class library. I'd love a "#include " trick :). Do I hack something together with webpack, etc?
Or... is there some accepted approach people use?
1.Can I call a UDF from a stored procedure directly, similar to how I've done it above in "processYay"? Or are they only accessible as
part of a query?
2.Can I call a UDF from another UDF, as I did inside "createYayDoc"?
3.Can a UDF 'throw' or is that considered a side effect in this case?
The answer is nope.You could find following clear statement in the official UDF doc.
User-defined functions (UDFs) are used to extend the Azure Cosmos DB
SQL query language grammar and implement custom business logic. They
can only be called from inside queries. They do not have access to the
context object and are meant to be used as compute-only JavaScript.
Therefore, UDFs can be run on secondary replicas of the Cosmos DB
service.
I think you have some misconceptions about the user defined function's application scenario. It just helps you process the result set of your query according to your custom business logic. It can not be invoked by stored procedure and can not call other methods or even manipulate the database.
Stored procedures are just JS code scripts which running on the server side.It can help you do some custom database operations ,even bulk operations. It's about special needs so that you can't think of it is an ordinary function in a complete project.
Considering reusability, you can pass some key variables in the JS code as parameters to the stored procedure.
Hope it helps you.
I faced problem, write unit test, using sqlite for it, for some query using doctrine extension for IF ELSE and when running test have error with that
for another error,md5 or concat I create sqlite function in PostConnectEventSubscriber class in postConnect function
in this part I use ifelse
this is my extension
Now I create stub without logic, but how implementation this for sqlite ?
$args->getConnection()
->getWrappedConnection()
->sqliteCreateFunction('IF', function ($st) {
return '';
});
SQLLite does not support advanced conditional statements, you should use CASE instead of IF...ELSE.
How is trigger function different from 'regular' functions? And is it absolutely necessary in creating a trigger?
For example, in this case:
-- Trigger function
CREATE FUNCTION update_record_trigger_function() RETURNS trigger
LANGUAGE plpgsql
AS $update_record_trigger_function$
BEGIN
PERFORM update_record(NEW.oid); -- helper function ...
RETURN NEW;
END
$update_record_trigger_function$;
-- Trigger for updating latest clicks for posts
CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW
EXECUTE PROCEDURE update_record_trigger_function();
Would it not be simpler to (or is it possible to do):
-- Trigger for updating latest clicks for posts
CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW
PERFORM update_record(NEW.oid); -- syntactically not right but along this idea
I wasn't able to find any document with examples of 'skipping trigger function' or one that explaining how trigger function is special and necessary for triggers?
PostgreSQL separates the "trigger function" from the trigger definition for quite a few reasons:
Trigger functions can be written as generic functions that can work on many different tables, so you can add the same trigger function as a trigger to many different tables. This eases maintenance.
Trigger functions can take parameters that allow them to adapt to specific column names or other characteristics of the table you apply them to. This makes it practical to write generic, re-usable trigger functions where you otherwise could not do so, so you often don't need to repeat the code in multiple places. See EXECUTE ... USING and the format function with its %L and %I format-specifiers.
PostgreSQL tries very hard not care what programming language your functions are written in . They could be PL/PgSQL, Python, Perl, C, or MyWackyPluginLanguage. If it didn't separate trigger function from trigger definition this would be harder to achieve.
The shorthand you describe is not supported in PostgreSQL, though some other database systems provide something very much like what you've shown. You essentially want to be able to define a trigger function as an inline expression. This isn't supported. There's never been a pressing need for it so nobody's implemented it.
If such a feature were added in future - and I'm not aware of any plans to do so - it would probably be done using a PL/PgSQL DO block that was contextually interpreted as a trigger, something like (not legal syntax):
CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW DO $$ PERFORM update_record(NEW.oid); RETURN NEW; $$;
That way the parser wouldn't need to understand PL/PgSQL constructs, we'd just have to teach it to understand FOR EACH ROW DO [string literal body of function] as an alternative to FOR EACH ROW EXECUTE PROCEDURE proc_name(args) and then invoke the PL/PgSQL subsystem to process the trigger literal.
In practice Pg would probably just generate an ordinary trigger function and add a reference to it from the trigger so it's dropped if the trigger was dropped, making this a just convenience macro, just like SERIAL is a convenience macro for an INTEGER field with a DEFAULT nextval(...) and a generated SEQUENCE owned by the table with the SERIAL field. In particular, pg_dump would probably output it as if you'd defined a separate trigger function and trigger, rather than used the shorthand.
Honestly, I doubt anything like this will ever be added, but if you can provide sufficiently convincing use cases you might if you're really lucky interest someone in it. Most likely you'll only get anywhere with such a proposal ("allow DO blocks to be used as trigger procedures") if you're willing to back it with funding for the time required to implement the feature.
As the Sqlite docs specify, unbound parameters in prepared statements are interpreted as NULL - my question is this then:
Is there a way to have Sqlite ensure that all parameters have been bound at least once, thereby ensuring none were missed by accident?
It is better to get an error and require calls to sqlite3_bind_null(statement_, col); then to get a subtle error because I forgot to call sqlite3_bind_* on the where clause of an update statement!
It is not possible to differentiate unbound parameters from parameters set to NULL using the current SQLite libraries.
If you have a look at the C source code for sqlite3_bind_null(), you will find that it simply calls the internal SQLite function that unbinds a parameter. Therefore there is no way to tell the two cases apart.
The only solution for this would be to wrap the SQLite C API functions with your own functions that will do a bit of book-keeping. You can bundle a bitmap with each sqlite3_stmt structure, with each bit set to true if and only if the corresponding parameter is bound. You would have to create wrappers for at least the sqlite3_bind_*() functions and sqlite3_clear_bindings().