A. Yes, we can create table with the help of SELECT INTO statement. It
copies content of one table to another table. However, there should be
at least one table from where we can copy content.
Example : Copying all columns : select * into new_table from old_table where
condition
Copying specific column : select col1,col2 into new_table from old_table
where condition
Creating new empty table : select * into new_table from old_table where 1
= 0

Q2. What is Denormalization ?

A. It is the reverse process of Normalization. It is the process of trying to
improve the readability of the database by grouping data. Denormalization
is also used for speeding up the performance.

Q3. What are Joins ?

A. Join clause are used to combine rows from two or more tables,
depending upon the columns between them.

Q4. What are the different types of Joins ?

A. Different types of Joins are :

1. INNER JOIN : It returns all records that are common in both tables.
2. LEFT OUTER JOIN : It returns all records from the left table, and matched records from right table
3. RIGHT OUTER JOIN : It returns all records from the right table, and matched records from left table.
4. FULL OUTER JOIN : It returns all records when there is a match in either left or right table.

Q5. Explain Transaction ?

A. Transaction refers to the collection of multiple statements, that are
responsible for transferring a database from one consistent state to another
consistent state.

Q6. Explain the role of views in database ?

A.View refers to the virtual table. We can create view using create view
statement.

CREATE VIEW as Select col1
FROM table1
where CONDITION;

Q7. Explain Trigger ?

A. Triggers are defined as special kind of stored programs, which are
automatically executed whenever a specific operation occurs in the
database server.

Q8. What are Locks ?

A. Locking is the mechanism to protect data integrity and ensure data
consistency during transactions. Locks are the most common cause of
blocked processes. Stronger the Isolation level, more the chances of
blocking.

Q9. Explain different types of Locks ?

A. Locks are broadly characterized into following types :

Shared Locks : These locks are acquired by readers during read
operations. In other words, these locks exist when two transactions are
granted read access. Data updation is not allowed until shared lock is
released.
Exclusive Locks : In exclusive lock, data items can be both read as well
as written by the transaction. In Exclusive lock, multiple transactions do not
modify the same data simultaneously.

Q10. What is Super Key ?

A. An attribute or set of attributes that uniqueness in database is refered to
as Super key. It is the superset of Candidate key.

Q11. What is Candidate Key ?

A. A minimal set of attribute/attributes that can be used to uniquely identify
a single row in a given relation is refered to as Candidate key.

Q12. Explain Primary Key ?

A. DB Designer selects one of the candidate key as primary key for a
relation for the purpose of identification of a tuple uniquely. It is identified
during table creation.

Q13. What is Composite Key ?

A. If a primary key has more than one attribute, then it is referred to as
Composite key.

Q14. Explain Foreign Key ?

A. A set of attribute/attributes that is used to establish and enforce a link
between data in two or more relations.

Q15. Can a table have more than one primary key ?

A. No.

Q16. Can We Have NULL Value in Primary Key?

A. No.

Q17. What are cursors ?

A. A cursor is a temporary work area created in system memory when a
SQL statement is executed. A cursor can hold more than one row, but can
process only one row at a time.

Q18.What are the differences between Hash join, Merge join and Nested loops?

Q19. What do you understand by Proactive, Retroactive and Simultaneous Update ?

1. Proactive Update: These updates are applied to the database before it becomes effective in the real-world environment.
2. Retroactive Update: These retroactive updates are applied to a database after it becomes effective in the real-world environment.
3. Simultaneous Update: These updates are applied to the database at the same instance of time as it becomes effective in a real-world environment.

Q20.What do you understand by Data Independence?

A. When you say an application has data independence, it implies that the application is independent of the storage structure and data access strategies of data.

The post DBMS Interview Q&A Part- 2 appeared first on scmGalaxy.

If you are using wget 1.11 against Jenkins version 1.586 and above with the JENKINS-25169 fix, you might need to use the following options:
wget –auth-no-challenge –http-user=user –http-password=apiToken –secure-protocol=TLSv1 http://jenkins.yourcompany.com/job/your_job/build?token=TOKEN

If you are using wget 1.11, you might need to use the following options:
wget –auth-no-challenge –http-user=user –http-password=apiToken http://jenkins.yourcompany.com/job/your_job/build?token=TOKEN

With wget 1.10.x the following is enough (but will not work with 1.11.x) :
wget http://user:apiToken@jenkins.yourcompany.com/job/your_job/build?token=TOKEN

If you are a Windows User!

‘gitbash’ is a program combined of git and bash. A bash is shell that runs commands once you type the name of command and press enter.

Download  the git bash from here https://git-scm.com/download/win and install it.

The post How to Trigger builds remotely in Jenkins? | Jenkins Tutorials | scmGalaxy appeared first on scmGalaxy.

Grep will return 0 while the build is running:

$ curl http://myjenkins/job/myjob/lastBuild/api/json | grep –color result\”:null

$ echo $?

Trigger a Jenkins Job from command line

$ wget http://yourserver/job/MyJobname/build?delay=0sec

$ wget -O – $HUDSON_URL/job/JOBNAME/build

Trigger a Jenkins Job without authentication

$ curl http://jenkins:8080/job/my%20job/build

Trigger a Jenkins Job with authentication

$ curl –user dbacher:$MY_API_TOKEN http://jenkins:8080/job/my%20job/build

$ curl –user <your_jenkins_username>:<your_jenkins_API_key> http://<jenkins_server_url>/job/<your_jenkins_job_name>/build

Running commands against a secure Jenkins (basic auth or ssh keys)

$ java -jar jenkins-cli.jar -s http://myjenkins help –username me –password mypassword

$ java -jar jenkins-cli.jar -s http://myjenkins help -i ~/.ssh/id_rsa

Triggering a job build against a secure Jenkins (avoiding a 1.5 year old open bug!)

$ java -jar jenkins-cli.jar -s http://myjenkins build ‘My Awesome Jenkins Job’ -i ~/.ssh/id_rsa

$ java -jar jenkins-cli.jar -s http://myjenkins build ‘My Awesome Jenkins Job’ -i ~/.ssh/id_rsa -s -v

Passing parameters when triggering a job build

$ java -jar jenkins-cli.jar -s http://myjenkins build ‘Deploy XYZ App’ -i ~/.ssh/id_rsa -s -v -p target_env=api.cloudfoundry.com -p branch=master

Reference

http://starkandwayne.com/articles/2013/04/12/jenkins-builds-from-cli/

http://www.scmgalaxy.com/index.php?option=com_k2&view=item&id=890:ways-to-login-jenkins-using-command-line&Itemid=120

Appendix

1. How to get your_jenkins_API_key?

• Login to your Jenkins.
• Click on the username in the top right.
• Click on Configure.
• Click on ‘Show API Token’ button.
• You got it.

The post Jenkins Command line Reference for login and trigger a job appeared first on scmGalaxy.

Reference: Apache Maven,Current version User Guide

Profiles in Maven

 Use of profile:

Maven 2.0 goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inhertiance,
dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.

However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different
dependency set will be required, and the project’s artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.

To address these circumstances, Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are
triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments
(providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is running with one POM only.

What are the different types of profile? Where is each defined?

• Per Project: Defined in the POM itself (pom.xml).
• Per User: Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
• Global: Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
• Profile descriptor: a descriptor located in project basedir (profiles.xml)

How can a profile be triggered? How does this vary according to the type of profile being used?

• A profile can be triggered/activated in several ways:
• Explicitly
• Through Maven settings
• Based on environment variables
• OS settings
• Present or missing files

Profiles can be explicitly specified using the -P CLI option.

This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.

mvn groupId:artifactId:goal -P profile-1,profile-2

Profiles can be activated in the Maven settings, via the section.

This section takes a list of elements, each containing a profile-id inside.

…

profile-1

…

Profiles listed in the tag would be activated by default everytime a project use it.

Profiles can be automatically triggered based on the detected state of the build environment.

These triggers are specified via an section in the profile itself. Currently, this detection is
limited to prefix-matching of the JDK version, the presence of a system property or the value of a
system property. Here are some examples.
The follwing configuration will trigger the profile when the JDK’s version starts with “1.4” (eg.
“1.4.0_08”, “1.4.2_07”, “1.4”):

1.4

…
The following honours versions 1.3, 1.4 and 1.5.

[1.3,1.6)

…
Note: an upper bound such as ,1.5] is likely not to include most releases of 1.5, since they will have an additional “patch” release such as _05 that is not taken into consideration in the above range.

This next one will activate based on OS settings.

See the Maven Enforcer Plugin for more details about OS values.

Windows XP
Windows
x86
5.1.2600

…
This will activate the profile when the system property “debug” is specified with any value:

debug

…
This example will trigger the profile when the system property “environment” is specified with the
value “test”:

environment
test

…
Note: Environment variable FOO would be set like env.FOO.

Present or missing files

To activate this you would type this on the command line: mvn groupId:artifactId:goal -Denvironment=test

This example will trigger the profile when the generated file target/generated-sources/axistools/wsdl2java/org/apache/maven is missing.

target/generated-sources/axistools/wsdl2java/org/apache/maven

…
Note: The tags and could be interpolated with some patterns like ${user.home}. Profiles can also be active by default using a configuration like the following:

profile-1

true

…
This profile will automatically be active for all builds unless another profile in the same pom is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the pom is activated on the command line or through its activation config. 20.1.2.2

Deactivating a profile

Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character ‘!’ or ‘-‘ as shown below:

mvn groupId:artifactId:goal -P !profile-1,!profile-2

This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.

Next ….? Coming Soon

The post Profiles in Maven – How to Build Maven Profile ? appeared first on scmGalaxy.

1 Introduction
Perforce introduced the first server-side trigger in release 99.1 with the pre-submit trigger. This trigger satisfied a long-standing desire in the user community, but demand continued for more hooks. In release 2004.2, Perforce squarely hit the need with the addition of five new trigger types. Release 2005.1 adds yet one more trigger type to this list rounding out one of the categories of triggers to completeness. This paper discusses triggers, techniques for implementing them and purposes for using them. It presumes a general knowledge of scripting. The examples follow in several programming languages. They should be easy to follow with knowledge of general programming, and any more arcane constructs will be explained. The paper also presumes a reasonable knowledge of Perforce scripting alternatives, such as that presented in [Bowles2005]. Although this paper will address the scripting of triggers comprehensively, it will refer to other Perforce scripting contexts and to Perforce commands with an assumption of familiarity.

1.1 What is a trigger?
Triggers are programs that run on the server immediately in response to some welldefined event in Perforce. Therefore, the context for a trigger is running on the server
using the trigger mechanism to start. Triggers are typically written in a shell script such as Perl, Python or Ruby due to the flexibility and facilities they provide. However, triggers can be written in any programming language that can interface with Perforce, including UNIX shell (sh, ksh, csh and work-alikes) and compiled languages like C/C++.

1.2 Types of triggers
Triggers fall into two categories. Pre-submit triggers enable actions in response to the submission of changelists. Form triggers allow actions in response to various stages of the life cycle of a form, regardless of the form type. This section provides a brief overview of the trigger types in preparation for the more detailed discussion.
1.2.1 Pre-submit triggers
There are three types of pre-submit triggers corresponding to different points in the life cycle of a submission.
• “Submit” triggers execute after the changelist has been created but before the files have been transferred, allowing inspection of the changelist details but disallowing file inspection.
• “Content” triggers execute after file transfer but before commit, allowing for inspection of the files.
• “Commit” triggers execute after the commit, allowing inspection of the changelist and file contents, but disallowing canceling of the submission.

1.2.2 Form triggers
Form triggers come in four types depending on the point in the form’s life cycle in which they are invoked.
• “Out” triggers execute when the form is generated and can modify the form before it is presented to the user.
• “In” triggers execute when the form is sent back to Perforce but before it is parsed, also allowing modification of the form on its way in.
• “Save” triggers execute after the form has been parsed but before it is saved, allowing reaction to the form but not modification.
• “Delete” triggers execute before a form is deleted, allowing failure of the deletion.

1.3 Why use a trigger?
Knowing why to use a trigger is partially a matter of knowing what are the competing alternatives. The alternatives naturally come from other contexts, since triggers define a context of their own. This section details the salient operational characteristics of triggers and contrasts them with Perforce alternatives. The three primary alternatives to triggers are wrapper scripts, such as p4wrapper, 1 review daemons, and journal tailers. A variation on the wrapper script would be a script available from the Tools menu in P4Win.

1.3.1 Synchronous execution
Triggers execute synchronously in response to their associated event. This provides an immediacy of response that is sometimes required or at least highly desirable. One option that provides synchronous execution could be an action invoked from a wrapper script such as p4wrapper. Another option would be to forego synchronous execution and rely on frequently running review daemons. Journal tailers would also perform asynchronously, although with very rapid and event-driven response.
1.3.2 Immediate user feedback on error
Triggers can provide messages back to the user, but only on error. Messages are not delivered on successful execution. A wrapper script can deliver messages to the user regardless of whether an error occurs or not. Review daemons and journal tailers can only provide feedback through indirect mechanisms.
1.3.3 Enforceability
Enforceability refers to the ability of an administrator to ensure that the script will run regardless of the client program used to initiate the operation. Because triggers are
installed on and executed by the server in response to server events, they will execute regardless of the client program. Wrapper scripts will only be invoked when the wrapper is used, whereas direct use of p4 or use of a different client program will circumvent the desired action. Review daemons and journal tailers are also enforceable due to their context on the server.

1.3.4 Modify a form
Form triggers can modify a form as it is delivered to the user or as it is sent back to Perforce. Wrapper scripts share this characteristic. Review daemons and journal tailers can not modify forms except to the extent that any user or administrator can after the operation has finished.
1.3.5 Customize any action
Form triggers have a limited ability to customize actions that involve forms, but they do not have the ability to react to any arbitrary command. Similarly, pre-submit triggers can only react to submits. Review daemons can only react to commands whose side effects can be reliably observed, something that is not readily available from the command line in many cases or from review mechanisms. Journal tailers have the ability to react to any action that affects database entries, which includes almost all.
1.3.6 Optimization for bulk processing
The review mechanism gives the ability to process a large number of actions in an orderly and efficient manner as long as those changes impact a counter. This optimization is not readily if at all available to triggers, wrappers or journal tailers due to their association with individual commands or journal entries.

1.3.7 Deterministic execution
Triggers and wrappers provide an exact and deterministic understanding of when they will execute relative to the command that initiates them. Review daemons are generally driven in a time-based manner and therefore do not execute deterministically relative to the Perforce command. Journal tailers are closer to deterministic than review daemons, but can conceivably execute prior to completion of a command.
1.3.8 Summary
The following table summarizes the characteristics of the scripting contexts that compete with triggers for Perforce scripting.

The post How to Write Trigger in Perforce? – Perforce Triggers Guide appeared first on scmGalaxy.