How does one use the dbms_standard package from Oracle? (Version 10g)
It's not described in the document PL/SQL Packages and Types Reference 10g Release 2 (10.2) B14258-02.
Oracle doesn't document it, because Oracle doesn't intend for its functionality to be directly used. This is the basic definitions for the SQL environment. You will see type definitions such as FLOAT, REAL, INTEGER, CHAR, etc. in here. Here is where functions that implement language features like SQLERRM are defined.
Why wouldn't they provide documentation for those that want it? Because Oracle wants and needs to be able to change this stuff at will, from release to release. They don't want to have any responsibility for applications that make use of the features in here when they break because Oracle needed to change something. Providing documentation encourages its use.
EDIT:
For the curious, you can take a peek at %ORACLE_HOME%\RDBMS\Admin\stdspec.sql (package spec) and stdbody.sql (package body), which are executed by the standard.sql script. WARNING: don't modify them! These files are in the RDBMS server Oracle home, not the client home.
Related
The title tells it all:
Does breezy fully replace bzr, at least in msys2?
E.g., by aliasing.
I found little info on this:
https://github.com/NixOS/nixpkgs/issues/80740
Yes, Breezy is a full replacement for Bazaar. It's derived from the Bazaar codebase, and compatible with the Bazaar command-line interface.
There are a large number of changes to the internal API, but unless you use third-party plugins or use scripts that use the bzrlib API, that should not be relevant to you.
We've also dropped support for a number of older platforms (e.g. Windows '95 and '98). I don't think msys2 was ever explicitly supported as a platform, but we're happy to help fix any issues you may run into. See https://www.breezy-vcs.org/pages/support.html for ways to reach out to us.
You can read more about the rationale for the fork here:
https://lists.ubuntu.com/archives/bazaar/2017q2/076170.html
https://www.jelmer.uk/breezy-intro.html
I have been reading about semver. I really like the general idea. However, when it comes to putting it to practice, I feel like I'm missing some key pieces of information. I'm not sure where the name of a library exists, or what to do with file variants. For instance, is the file name something like [framework]-[semver].min.js? Are there popular JavaScript frameworks that use semver? I don't know of any.
Thank you!
Let me try to explain you.
If you are not developing a library that you like to keep for years to come, don't bother about it.. If you prefer to version every development, read the following.
Suppose you are an architect or developer developing a library that is aimed to be used by hundreds of developers over time, in a distributed manner. You really need to be cautious of what you are doing, what your developers are adding (so interesting features that grabs your attention to push those changes in the currently distributed file). You dont know how do you tell your library users to upgrade. In what scenarios? People followed some sort of versioning, and interestingly, their thoughts all are working fine.
Then why do you need semver ?
It says "There should be a concrete specification for anything for a group of people to follow anything collectively, even though they know it in their minds". With that thought, they made a specification. They have made their observation and clubbed all the best practices in the world about versioning software mainly, and given a single website where they listed them. that is semver.org. Its main principles are :
Imagine you have already released your library with a version "lib.1.0.98", Now follow these rules for subsequent development.
Let your library is bundled and named as xyz and,
Given a version number MAJOR.MINOR.PATCH, (like xyz.MAJOR.MINOR.PATCH), increment the:
1. MAJOR version when you make incompatible API changes
(existing code of users of your library breaks if they adapt this without code changes in their programs),
2. MINOR version when you add functionality in a backwards-compatible manner
(existing code works, and some improvements in performance and features also), and
3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
If you are not a developer or are not in a position to develop a library of a standard, you need not worry at all about semver.
Finally, the famous [d3] library follows this practice.
Semantic Versioning only defines how to name your versions. It does not specify what you will do with your version number afterwards. You can put the version numbers in package names, you can store it in a properties file inside your application, or just publish it in a wiki. All those options are opened to discussion and not part of the problem space addressed by SemVer.
semver is used by npm and bower (and perhaps some other tools) for dependency management. Using semver it is possible to decide which versions of which packages to use if multiple libraries used depend on the same library.
As others have said, semantic versioning is a standard versioning scheme that tells your users which versions of your library should be compatible with each other, and which ones are not.
The idea, is to be able to give your users more confidence that it's safe to upgrade to a newer patch/version, because it's tried, tested, and true to being backwards compatible with the previous version (minor increments). That is, perceptively that's what your telling your users.
As far as tooling goes, I don't do much in javascript, but I typically let my build server handle stamping my assemblies etc with the correct version. I have a static major number I upgrade whenever I make breaking changes, a static minor number I upgrade everytime I add new features, and an auto-incrementing Patch number whenever I checkin bug fixes.
Especially if this is a javascript library you plan to share on a public repository of some kind (nuget, gem, etc) you probably want some for of automated packaging system, and you put the logic in there for specifying your version number (in the package meta data, in the name of the javascript file, which is typically the standard I've seen).
Take a look at sbt which is the Scala Build Tool. In it, we write dependencies like this:
val scalatest = "org.scalatest" %% "core" % "2.1.7" "test"
val jodatime = "org.joda" % "jodatime" % "1.4.5"
Wherein the operator %% means "the current version of Scala that you're building." Packaging things in this language generally create JAR files with the name like this <my project>_<scala version>_<library version>.jar which is quite handy for semantically naming things automagically. The % operator can be interpreted as "don't version this part."
That said, this resulted from the fact that the same library compiled to different Scala versions were not binary compatible with each other. So it was more as a result of, rather than a conscious design choice, the binary incompatibilities.
Hello I was trying to learn db2 sql and I was having some problems.
I want to bind a package, but I don't have any packages to bind.
So when I try to create a package it obviously gives me an error. I know that a package is created when we create a database. But then why doesn't it list any packages when i do
db2 list packages
I have seen a lot of links but no help. I would really appreciate if someone actually explained it to me.
Thank you very much
In order to understand a package, you first need to understand dynamic and static queries.
Dynamic queries are created at execution time. Everything from PHP, Perl, Python, Ruby or Java (JDBC) are Dynamic queries. For example, when using Java, you get a Prepared statement, and you assign values (setXXX) to the parameter markers (?).
However, there are other programming languages, such as C, Java (sqlj), cobol, where you create the program, with embedded SQL. For example, when using SQLj, you write a class in a .sql file, and the queries are written in specific tags (not java, but started with #sql { }), then you do a precompilation, that is a process where the SQL are taken out from the code, and translated to natural programming language (ie. from sqlj to Java). The SQL in then inserted into a file that is called a bind file. Once you have that, you need to compile the code (javac to create the .class) and bind the file in the database. In this last step is where the packages are created.
A package is a set of data access plans. However, they were calculated at the bind time, not at the execution time, like in the dynamic queries. They are difference between them.
Finally, in order to create a package, you need to change the bind properties, and eventually the bind file itself.
I am using Oracle 9i and want to know to the definition(code) of predefined
functions in Oracle like,REVERSE(),REPLACE().
Is there any library of oracle where i can serach these library functions!
Please Suggest!!
Nope. Oracle wraps the body (implementation) of virtually all of its packages, and the functions you've mentioned are part of the STANDARD package.
I've inherited a collection of largely undocumented ssis packages. The entry point package (ie: the one that forks off in a variety of directions to call other packages) defines a number of variables. I would like to know how these variables are being used, but there doesn't seem to be an equivalent of "right click/Find All References"
Is there a reliable way to determine where these variables are being used?
A hackish way would be to open the dtsx file in a text editor/xml viewer and search for the variable name.
If it's being used in expressions, it should show it and you can trace the xml tree back up until you find the object it's being used on.
You can use the bids helper add-in thats gives you visual feedback on where variables are used in your package. Thats makes it very fast and easy to detect them.Besides that, it offers several other valueable features.
Check out: http://bidshelper.codeplex.com/