I have several table-valued overloaded procedures in my PostgreSql database. They have the same name, but different number of parameters. As JOOQ 3.5 treats those procedures as tables, generator discovers only one procedure with that name. Is it designed this way, or is there a workaround?
GeneratorStrategy doesn't help as this happens earlier, when database.getTables(schema) in Generator is Called.
This is a bug (#4055) in jOOQ 3.5.2. jOOQ currently doesn't support overloaded table-valued functions.
The only workaround I can think of is to resort to plain SQL for those functions.
Related
I have been using the Schema.getTables() method in jOOQ to get the list of tables in my schema, but today I found out that method is returning the list of tables that existed when we executed jOOQ's code-generation, not the tables that exist at this point in time.
My specific use case is we create tables over time (automatic partitions) and our Java service does some operation on them.
Is there a way in jOOQ to get the current list of tables from the DB?
I could resort to querying information_schema.tables directly, but I'd prefer to reuse a method from jOOQ if one is available.
You can access your runtime meta information via jOOQ's DSLContext.meta() API, which is a jOOQ wrapper over JDBC's DatabaseMetaData.
In Transact-SQL for Azure SQL Database, is there any facility in stored procedures or user-defined functions to include or reference another unit to get common definitions? I frequently cut and paste variables used as constant definitions between procedures and am looking for a better way. I am aware of user-defined table types.
From comment by TT: No. T-SQL by itself has no such concept.
I have a really old PostgreSQL version - 8.3 and we would like to upgrade it to 8.4. It shouldn't be hard but I am worrying what will happen when function written by my own was added in newer version. By example I wrote function A(text) and function with exactly the same name and parameter was added in PostgreSQL 8.4. What will happen? My function will get override, I'll get some conflict or my function will be the valid one and PostgreSQL won't add it's own?
All built-in functions are stored in the schema pg_catalog. All functions you wrote yourself are stored in a different schema (typically public).
As the "primary key" to identify a function is the schema and the name, there is no clash between your functions and any built-in function.
How do I use Slick to call a stored procedure?
I want it to be type safe / injection safe. (ie, I don't want any SQL query strings in my code...)
According to the docs, Slick includes "Type-safe support of stored procedures" (http://slick.typesafe.com/doc/1.0.0/introduction.html)
But I do not see any example in the docs of how to do it.
That's a typo. It should read "Type-safe support of scalar database functions". At the moment you have to use plain SQL to call stored procedures.
Also see https://groups.google.com/forum/#!searchin/scalaquery/procedure/scalaquery/BUB2-ryR0bY/EFZGX663tRYJ
A general question.
I am developing for Sybase SQL Anywhere 10. For backwards comptibility reasons, almost all our Stored procedures are written in Transact-SQL.
Are there any advantages or disadvantages to using T-SQL instead of the Watcom dialect?
Advantages of TSQL:
greater compatibility with Sybase ASE and Microsoft SQL Server
Disadvantages of TSQL:
some statements and functionality are only available in Watcom-SQL procedures. Some examples:
greater control over EXECUTE IMMEDIATE behavior in Watcom-SQL
LOAD TABLE, UNLOAD TABLE, REORGANIZE (among others) are only available in Watcom-SQL
the FOR statement for looping over the results of a query and automatically declaring variables to contain the values is very useful, but not available in TSQL
error reporting is less consistent since TSQL procedures are assumed to handle their own errors, while Watcom-SQL procedures report errors immediately. Watcom-SQL procedures can contain an EXCEPTION clause to handle errors
statements are not delimited by semi-colons, so TSQL procedures are more difficult to parse (and read). Syntax errors can sometimes fail to point to the actual location of the error
no ability to explicitly declare the result set of a procedure
no support for row-level triggers in TSQL
event handlers can only be written using Watcom-SQL
The documentation for SQL Anywhere T-SQL compatibility is available online. There are some database options that change behaviour to more closely match what you would expect from Sybase ASE. In addition, there are some functions that can be used to translate from one syntax to another.
Note that if you want to start adding statements in the Watcom dialect into an existing stored procedure, you will need to change the SP so that it is entirely written in the Watcom dialect. You cannot mix syntaxes in a SP, trigger, or batch.
What KM said - on the other hand, the "Watcom" dialect is much closer to ISO/ANSI-standard SQL, so that dialect is more likely to match to some other products and to appeal to people familiar with SQL standards.
if you ever try to port to SQL Server (or you go for a job on SQL Server), Sybase T-SQL is very close to SQL Server T-SQL. Sybase and MS joined up back in the day, so the core of those languages are very similar.