What language do you use to write stored procedures/functions in Mariadb?
Like PL/SQL in oracle, is there an equivalent language in Mariadb?
Thanks
Stored procedures and functions are written in SQL. Refer to MariaDB's Programmatic and Compound Statements and CREATE PROCEDURE documentation.
As of MariaDB 10.3 (GA since 25. May 2018), a subset of PL/SQL is actually supported in stored procedures and functions with SET sql_mode=ORACLE.
See this page for details:
https://mariadb.com/kb/en/library/sql_modeoracle-from-mariadb-103/
MariaDB follows the MySQL coding format. You can use the way we write in MySQL.
Also you can use MySQL workbench as a client to smooth work.
Related
I have to write JUnit test cases for REST API created using Spring boot and Oracle. There is no dedicated test DB environment. So I planned to use the in-memory database. I did a POC on H2 database. Even after spending 3 days, I was able to do basic things but it is not fully compatible with Oracle. It didn't support In, Out parameter, also it didn't support "call schema.package.function(In, Out)". I was able to create schema and function but I was not able to create a package. Could you please suggest an in-memory which support the following
Should support schema, package and function creation.
Should support In, Out parameter
Should be lightweight
Should be compatible with Oracle and Java
HSQLDB supports IN and OUT parameters for PROCEDURES. You can mimic the schema.package.function(in, out) by renaming the database CATALOG as the name of the schema and creating a separate schema named as the package, then creating the function in that schema.
Alternatively, HyperXtremeSQL (http://hyperxtreme.co.uk) supports creation of package, procedure and function with Oracle syntax.
I'm retrospectively unit testing a zend application and want to use an SQL Lite database for convenience. In production we use MySQL updated with DB migrations. Simple question: How do I create an SQL Lite schema? Is it possible to automatically recreate the schema inside phpunit?
Many thanks for your help.
Are you using doctrine?
If so, you can generate the schema with doctrine's orm:schema-tool:create feature.
You can use this command to either dump the SQL, or generate your tables directly through the connection.
Flyway offers a oracle pl/sql parser, so is it possible using a pl/sql dump (.pde) for a migration?
The dump must be in .sql format. Binary exports are not supported.
There are statements like
SET server output ON
PRINT var_name
DEFINE var_name
VARIABLE var_name
etc. which are typed outside the PL/SQL block. These are SQL+ commands which also seem to work on SQlDeveloper, both of which are tools to execute PL/SQL scripts in. Is there any standard that these non-PL/SQL commands follow, i.e. since they are tool-specific, they can differ, say in, SqlDeveloper and SqlPlus. Whose statements should I learn ?
You should learn the commands supported by the tool you are using - SQL Plus commands for SQL Plus, etc. There is overlap between SQL Plus and SQL Developer because SQL Developer has been designed to be easy to use by people who have previously used SQL Plus. To see which SQL Plus commands SQL Developer supports, open its online help and navigate to:
SQL Developer Concepts and Usage
Using the SQL Worksheet
SQL*Plus Statements Supported and Not Supported in SQL Worksheet
how can i use SQL statement in CoreData database ? which part of CoreData hand it ? thanks
and how can i fetch only last elements, not all ?
If it were possible to write your own SQL statements and have them executed through the Core Data framework, I think it would be described in the documentation for NSPersistentStore or one of its related classes. As far as I can tell, it isn't.
You can always use SQLite directly to load in (and query) the Core Data database without going through the Core Data framework. This can be done either by using SQLite's own APIs, or the sqlite3 program that should already be installed on your Mac. I'm not sure why you'd want to do this on a database that's already managed by Cora Data, though.