Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • Identify correct and incorrect syntax for an EJB QL query including the SELECT, FROM, and WHERE clauses.

    EJB QL is a query specification language for the FINDER and SELECT methods of entity beans with container-managed persistence (CMP). EJB QL can be compiled to a target language, such as SQL, of a database or other persistent store. This allows the execution of queries to be shifted to the native language facilities provided by the persistent store, instead of requiring queries to be executed on the runtime representation of the entity beans' state. As a result, query methods can be optimizable as well as portable.

    The Enterprise JavaBeans query language uses the abstract persistence schemas of entity beans, including their relationships, for its data model. It defines operators and expressions based on this data model. The Bean Provider uses EJB QL to write queries based on the abstract persistence schemas and the relationships defined in the deployment descriptor. EJB QL depends on navigation and selection based on the cmp-fields and cmr-fields of the related entity beans. The Bean Provider can navigate from an entity bean to other entity beans by using the names of cmr-fields in EJB QL queries.

    When defining EJB QL, we are limited to referring only to elements described below:

    • Names of the entity beans defined in the abstract schema. Each bean by default is given the schema name of the bean (such as Customer, which is defined in the abstract-schema-name xml tag in DD).

      
      <entity>
      	<ejb-name>CustomerEJB</ejb-name>
      	...
      	<abstract-schema-name>Customer</abstract-schema-name>
      	...
      </entity>
      
      								

    • CMP field names within these beans (such as firstName, lastName, anything in a cmp-field tag in DD).

      
      <entity>
      	<ejb-name>CustomerEJB</ejb-name>
      	...
      	<abstract-schema-name>Customer</abstract-schema-name>
      	<cmp-field><field-name>id</field-name></cmp-field>
      	<cmp-field><field-name>lastName</field-name></cmp-field>
      	<cmp-field><field-name>firstName</field-name></cmp-field>
      	<cmp-field><field-name>hasGoodCredit</field-name></cmp-field>
      	...
      </entity>
      
      								

    • CMR field names within these beans to navigate along relationships (such as anything defined in a cmr-field).

      
      <ejb-relation>
      	<ejb-relation-name>Customer-HomeAddress</ejb-relation-name>
      	<ejb-relationship-role>
      		<ejb-relationship-role-name>
      			Customer-has-a-Address
      		</ejb-relationship-role-name>
      		<multiplicity>One</multiplicity>
      		<relationship-role-source>
      			<ejb-name>CustomerEJB</ejb-name>
      		</relationship-role-source>
      		<cmr-field>
      			<cmr-field-name>homeAddress</cmr-field-name>
      		</cmr-field>
      	</ejb-relationship-role>
      	<ejb-relationship-role>
      	...
      	</ejb-relationship-role>
      </ejb-relation>
      
      								

    An EJB QL query is a string which consists of the following three clauses:

    • a SELECT clause, which determines the TYPE of the objects or values to be selected.

    • a FROM clause, which provides declarations that designate the DOMAIN to which the expressions specified in the SELECT clause and WHERE clause of the query apply.

    • an optional WHERE clause, which may be used to RESTRICT the results that are returned by the query.

    EJB QL :: = SELECT_clause FROM_clause [WHERE_clause]

    An EJB QL query MUST always have a SELECT and a FROM clause. The WHERE clause is OPTIONAL.

    An EJB QL query MAY have parameters that correspond to the parameters of the finder or select method for which it is defined.

    An EJB QL query is statically defined in the ejb-ql deployment descriptor element. There must be ONE ejb-ql tag per query definition for each finder and select method.

    
    <entity>
    	<ejb-name>CustomerEJB</ejb-name>
    	...
    	<abstract-schema-name>Customer</abstract-schema-name>
    	<cmp-field><field-name>id</field-name></cmp-field>
    	<cmp-field><field-name>lastName</field-name></cmp-field>
    	<cmp-field><field-name>firstName</field-name></cmp-field>
    	<cmp-field><field-name>hasGoodCredit</field-name></cmp-field>
    	...
    	<query>
    		<query-method>
    			<method-name>findByName</method-name>
    			<method-params>
    				<method-param>java.lang.String</method-param>
    				<method-param>java.lang.String</method-param>
    			</method-params>
    		</query-method>
    		<ejb-ql>
    			SELECT OBJECT(c) FROM Customer c
    			WHERE c.lastName = ?1 AND c.firstName = ?2
    		</ejb-ql>
    	</query>
    
    	<query>
    		<query-method>
    			<method-name>findByGoodCredit</method-name>
    			<method-params/>
    		</query-method>
    		<ejb-ql>
    			SELECT OBJECT(c) FROM Customer c
    			WHERE c.hasGoodCredit = TRUE
    		</ejb-ql>
    	</query>
    
    	<query>
    		<query-method>
    			<method-name>ejbSelectLastNames</method-name>
    			<method-params/>
    		</query-method>
    		<ejb-ql>
    			SELECT c.lastName FROM Customer AS c
    		</ejb-ql>
    	</query>
    	...
    </entity>
    
    					

    EJB QL is used for two types of query methods:

    • FINDER METHODS. Finder methods are defined in the HOME interface(s) of an entity bean and return entity objects or local entity objects (NOTE, they can return ONLY COMPONENT INTERFACES). A finder method that is defined on the remote home interface must return either an EJBObject or a collection of EJBObjects; a finder method that is defined on the local home interface must return either an EJBLocalObject or a collection of EJBLocalObjects. The result type of a finder method defined on the remote home interface of an entity bean is the entity bean's remote interface (or a collection of objects implementing the entity bean's remote interface). The result type of a finder method defined on the local home interface of an entity bean is the entity bean's local interface (or a collection of objects implementing the entity bean's local interface).

    • SELECT METHODS. Select methods are a special type of query method NOT DIRECTLY EXPOSED through the client view. The Bean Provider typically uses select methods to select the persistent state of an entity object or to select entities that are related to the entity bean for which the query is defined. The result type of a select method can be an EJBLocalObject (or a collection of EJBLocalObjects), an EJBObject (or a collection of EJBObjects), or a cmp-field value (or a collection of such). NOTE, the SELECT method can return not only component interfaces, but also java.lang.Object, or COLLECTION of java.lang.Object.

    Reserved words are (keywords are NOT case sensitive): SELECT, FROM, WHERE, DISTINCT, OBJECT, NULL, TRUE, FALSE, NOT, AND, OR, BETWEEN, LIKE, IN, AS, UNKNOWN, EMPTY, MEMBER, OF, IS and ?.

    SELECT clause

    The SELECT clause defines the objects that are returned from a query.

    select_clause ::== SELECT [DISTINCT] {single-valued-path-expr} | OBJECT(ident_var)

    All standalone identification variables in the SELECT clause must be qualified by the OBJECT operator. The SELECT clause must not use the OBJECT operator to qualify path expressions.

    The following example returns a collection of the CMP fields of type lastName (a collection of Strings):

    SELECT cust.lastName FROM Customer AS cust
    					

    The following example returns a collection of Customer instances:

    SELECT OBJECT(cust) FROM Customer AS cust
    					

    The optional keyword DISTINCT effects a removal of duplicates in the returned collection.

    If the EJB QL query is specified for a method whose return type is java.util.Collection, the collection of values returned by the Container may contain duplicates if DISTINCT is not specified in the SELECT clause. If the query is specified for a method whose result type is java.util.Set, but does not specify DISTINCT, the container must interpret the query as if SELECT DISTINCT had been specified.

    FROM clause

    The FROM clause defines the set of beans from which the query results are formed and which are used in the WHERE clause.

    FROM_clause ::== FROM ident_variable_d {,ident_variable_d}

    ident_variable_d ::= collection_member_d | range_variable_d

    Identification variables can be either declared by using a range variable declaration (AS) or a collection member declaration (IN). Identification variables can only be declared in the FROM clause. Keep in mind that the statement is evaluated from the left to the right side. This is important for referencing within declarations to other variable declarations; referenced identifiers must already be declared. Unlike a Java variable, an EJB QL identifier IS NOT case sensitive.

    range_variable_d ::= abstract_schema_name [AS] identifier

    The AS keyword is optional. It is assumed if we omit it.

    SELECT OBJECT(cust) FROM Customer AS cust
    
    SELECT OBJECT(cust) FROM Customer cust
    					

    collection_member_d ::== IN collection_valued_path_expr [AS] identifier

    A collection member declaration declares an identification variable that represents an entity that is reached by navigating a CMR field in one-to-many or many-to-many relationships:

    SELECT OBJECT(cust) FROM Customer AS cust, IN(cust.accounts)
    
    SELECT OBJECT(acct) FROM Account AS acct, IN(acct.transrecords)
    					
    The IN specification enables us to use attributes of related entities in the WHERE clause of the EJB QL statement.

    With a PATH EXPRESSION, we can address a CMP or a CMR field of a specified type. With path expressions, we are able to navigate along the container-managed relationships between entity beans. The navigation operator dot separates the type from the attribute, for example customer.accounts. A path expression that ends in a cmp-field is terminal and cannot be further composed.

    Navigation to a related entity beans results in a value of the related entity bean's abstract schema type.

    It is syntactically illegal to compose a path expression from a path expression that evaluates to a collection. To handle such a navigation, an identification variable must be declared in the FROM clause to range over the elements of the collection. Another path expression must be used to navigate over each such element in the WHERE clause of the query.

    SELECT OBJECT(o)
    FROM Order AS o, IN(o.lineItems) l
    WHERE l.product.name = 'widget'
    					

    WHERE clause

    As in SQL the WHERE clause contains a conditional expression. The WHERE clause is optional in a query statement.

    WHERE_clause ::== WHERE conditional_expr

    conditional_expr ::== conditional_term | conditional_expr {OR | AND} conditional_term

    A conditional expression consists of other conditional expressions, logical or comparison operations or path expressions. At the end they have to evaluate to boolean values or boolean literals.

    Conditional expressions can use:

    • operators (+ - * /)

    • comparisons (= > >= < <= <>), for strings only = and <>

    • NOT

    • BETWEEN arithmetic-expression AND arithmetic-expression

    • IN: value IN (value1, value2, ...)

    • LIKE, using wild card characters _ and %

    • null comparison: IS NULL

    • empty comparison: collection-valued-path-expr IS EMPTY

    • collection member expression: MEMBER OF collection-valued-path-expr

    • functional expressions: CONCAT, SUBSTRING, LOCATE, LENGTH, ABS, SQRT

    To pass parameters to the query statement, the declared parameters of the finder method are accessible in the query statement as a question mark followed by a number, such as, ?1, ?2, ?3. The number is the position of the declaration in the finder method's signature. Input parameters are numbered starting from 1. The number of distinct input parameters in an EJB QL query must not exceed the number of input parameters for the FINDER or SELECT method. It is not required that the EJB QL query use all of the input parameters for the FINDER or SELECT method.

    For example, matching finder method declaration and EJB QL statements are:

    findCustomerByName(String lastName, String firstName);
    					
    SELECT OBJECT(c) FROM Customer c WHERE c.lastName = ?1 AND c.firstName = ?2
    					

    The type of the parameter in the statement is defined by the declaration of the correspondent parameter in the finder method signature. Parameters can be primitive types (int), wrapper classes (Integer) or EJB objects.

    Using a parameter is only allowed in the WHERE clause within a conditional expression that involves a single-valued path expression, such as x.lastName.

    The information you are posting should be related to java and ORACLE technology. Not political.