Skip to main content

Home/ SoftwareEngineering/ Group items tagged query

Rss Feed Group items tagged

kuni katsuya

Pro JPA 2: Mastering the Java™ Persistence API > Advanced Topics > SQL Querie... - 0 views

  • queries are also known as native queries
  • SQL Queries
  • reasons why a developer using JP QL might want to integrate SQL queries into their application
  • ...32 more annotations...
  • JPA 2.0, still contains only a subset of the features supported by many database vendors
  • features not supported in JP QL.
  • performance required by an application is to replace the JP QL query with a hand-optimized SQL version. This may be a simple restructuring of the query that the persistence provider was generating, or it may be a vendor-specific version that leverages query hints and features specific to a particular database.
  • recommend avoiding SQL initially if possible and then introducing it only when necessary
  • benefits of SQL query support is that it uses the same Query interface used for JP QL queries. With some small exceptions that will be described later, all the Query interface operations discussed in previous chapters apply equally to both JP QL and SQL queries.
  • keep application code consistent because it needs to concern itself only with the EntityManager and Query interfaces.
  • An unfortunate result of adding the TypedQuery interface in JPA 2.0 is that the createNativeQuery() method was already defined in JPA 1.0 to accept a SQL string and a result class and return an untyped Query interface
  • consequence is that when the createNativeQuery() method is called with a result class argument one might mistakenly think it will produce a TypedQuery, like createQuery() and createNamedQuery() do when a result class is passed in.
  • @NamedNativeQuery
  • resultClass=Employee.class
  • The fact that the named query was defined using SQL instead of JP QL is not important to the caller
  • SQL Result Set Mapping
  • JPA provides SQL result set mappings to handle these scenarios
  • A SQL result set mapping is defined using the @SqlResultSetMapping annotation. It may be placed on an entity class and consists of a name (unique within the persistence unit) and one or more entity and column mappings.
  • entities=@EntityResult(entityClass=Employee.class)
  • @SqlResultSetMapping
  • Multiple Result Mappings
  • A query may return more than one entity at a time
  • The SQL result set mapping to return both the Employee and Address entities out of this query
  • emp_id, name, salary, manager_id, dept_id
  • address_id, id, street, city, state, zip
  • order in which the entities are listed is not important
  • ntities={@EntityResult(entityClass=Employee.class), @EntityResult(entityClass=Address.class)}
  • expected result type and therefore received an instance of TypedQuery that is bound to the expected type. By qualifying the result type in this way, the getResultList() and getSingleResult() methods return the correct types without the need for casting.
  • Defining a Class for Use in a Constructor Expression
  • public EmpMenu(String employeeName, String departmentName)
  • List<EmpMenu>
  • NEW example.EmpMenu(" + "e.name, e.department.name)
  • EmpMenu.class
  • createNamedQuery() can return a TypedQuery whereas the createNativeQuery() method returns an untyped Query
  • List<Employee>
  • createNamedQuery("orgStructureReportingTo", Employee.class)
kuni katsuya

schuchert - JPA Tutorial 4 - Inheritance and Polymorphic Queries - 0 views

  • JPA Tutorial 4 - Inheritance and Polymorphic Queries
  • Books and Dvd's, both of which inherit from Resource
  • When we search for a Resource we might get back Books, Dvd's, or both
  • ...12 more annotations...
  • queries polymorphic
  • Introduce the Resource class
  • new type, Dvd
  • What happens when you perform a query on a type that has subclasses?
  • It turns out support for inheritance in queries (as well as JPA) is built in
  • do not actually need to do anything other than have one entity inherit from another entity to get everything to work
  • book entity inherit from the Resource entity
  • Introduce a new entity type called Resource
  • Change the BookDao to be a ResourceDao
  • Update the methods returning Book and have them instead return Resource
  • Update all references to Book and replace them with Resource
  • Change the bookId to resourceId
kuni katsuya

SQL Injection Prevention Cheat Sheet - OWASP - 0 views

  • SQL Injection Prevention Cheat Sheet
  • it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.
  • create dynamic database queries that include user supplied input
  • ...19 more annotations...
  • a) stop writing dynamic queries
  • b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query
  • Primary Defenses:
  • Option #1: Use of Prepared Statements (Parameterized Queries)
  • Option #3: Escaping all User Supplied Input
  • Additional Defenses:
  • Enforce: Least Privilege
    • kuni katsuya
       
      least privilege should be *required*, included as a primary defense
  • Perform: White List Input Validation
  • Primary Defenses
  • Defense Option 1: Prepared Statements (Parameterized Queries)
  • attacker is not able to
  • change the intent
  • of a query, even if SQL commands are inserted by an attacker
  • allows the database to
  • distinguish
  • between
  • data,
  • code a
  • Defense Option 3: Escaping All User Supplied Input
kuni katsuya

JPA implementation patterns: Retrieving entities | Xebia Blog - 0 views

  • JPA implementation patterns: Retrieving entities
  • two ways to retrieve an entity with JPA:
  • EntityManager.find
  • ...2 more annotations...
  • Query object that can then be executed to return a list of entities or a single entity.
  • Keeping the query and the code that sets these parameters together makes them both easier to understand
kuni katsuya

Preventing SQL Injection in Java - OWASP - 0 views

  • Preventing SQL Injection in Java
  • inject (or execute) SQL commands within an application
  • Defense Strategy
  • ...19 more annotations...
  • To prevent SQL injection:
  • All queries should be
  • parametrized
  • All dynamic data
  • should be
  • explicitly bound to parametrized queries
  • String concatenation
  • should never be used
  • to create dynamic SQL
  • OWASP SQL Injection Prevention Cheat Sheet.
  • Parameterized Queries
  • Prepared Statements
  • automatically be escaped by the JDBC driver
  • userId = ?
  • PreparedStatement
  • setString
  • Dynamic Queries via String Concatenation
  • never construct SQL statements using string concatenation of unchecked input values
  • dynamic queries via the java.sql.Statement class leads to SQL Injection
kuni katsuya

Why you should never use getSingleResult() in JPA | Sysout.be - 0 views

  • The only use for getSingleResult() is when we are
  • executing a scalar (count, sum, avg) query
  • query wich will
  • ...8 more annotations...
  • alway
  • return a row
  • 3 ways to do this
  • EntityManger.find()
  • returns a typed instance of the entity when it is found, null when it is not found
  • But what if the row isn’t in the database (anymore)?
  • We get an unchecked exception: NoResultException
  • We never know for sure what we can expect from our database, so throwing an unchecked exception seems the wrong choice for this use-case
    • kuni katsuya
       
      thinking defensively, in a pathological scenario, the data and/or schema of the database could be corrupt eg. using a named query that should return a single entity based on a unique constraint of a table: - what if the unique constraint was implemented incorrectly in the ddl? (too relaxed or too strict) - what if the data became inconsistent as a result of some external process? => should always code defensively, especially at integration points to anything external to the jvm 
kuni katsuya

Java Persistence/Querying - Wikibooks, open books for an open world - 0 views

  • Result Set Mapping
  • When a native SQL query returns objects, the SQL must ensure it returns the correct data to build the resultClass using the correct column names as specified in the mappings. If the SQL is more complex and returns different column names, or returns data for multiple objects then a @SqlResultSetMapping must be used.
  • @NamedNativeQuery
  • ...7 more annotations...
  • resultClass=Employee.class
  • class Employee
  • createNamedQuery("findAllEmployeesInCity")
  • List<Employee>
  • @NamedNativeQuery
  • resultSetMapping="employee-address"
  • @SqlResultSetMapping(name="employee-address", entities={ @EntityResult(entityClass=Employee.class), @EntityResult(entityClass=Address.class)} )
  •  
    Result Set Mapping
kuni katsuya

Permissions | Apache Shiro - 0 views

  • Permission as a statement that defines an explicit behavior or action
  • lowest-level constructs in security polices
  • explicitly define only "what" the application can do
  • ...69 more annotations...
  • do not at all describe "who" is able to perform the action(s)
  • Multiple Parts
  • Wildcard Permissions support the concept of multiple levels or parts. For example, you could restructure the previous simple example by granting a user the permission printer:query
  • Multiple Values Each part can contain multiple values. So instead of granting the user both the "printer:print" and "printer:query" permissions, you could simply grant them one: printer:print,query
  • All Values What if you wanted to grant a user all values in a particular part? It would be more convenient to do this than to have to manually list every value. Again, based on the wildcard character, we can do this. If the printer domain had 3 possible actions (query, print, and manage), this: printer:query,print,manage
  • simply becomes this: printer:*
  • Using the wildcard in this way scales better than explicitly listing actions since, if you added a new action to the application later, you don't need to update the permissions that use the wildcard character in that part.
  • Finally, it is also possible to use the wildcard token in any part of a wildcard permission string. For example, if you wanted to grant a user the "view" action across all domains (not just printers), you could grant this: *:view Then any permission check for "foo:view" would return true
  • Instance-Level Access Control
  • instance-level Access Control Lists
  • Checking Permissions
  • SecurityUtils.getSubject().isPermitted("printer:print:lp7200")
  • printer:*:*
  • all actions on a single printer
  • printer:*:lp7200
    • kuni katsuya
       
      note: wildcard * usage for 'actions' part
  • missing parts imply that the user has access to all values corresponding to that part
  • printer:print is equivalent to printer:print:*
  • Missing Parts
  • rule of thumb is to
  • use the most specific permission string possible
  • when performing permission checks
  • first part is the
  • domain
    • kuni katsuya
       
      aka 'resource'
  • that is being operated on (printer)
  • second part is the
  • action
  • (query) being performed
  • There is no limit to the number of parts that can be used
  • three parts - the first is the
  • domain
  • the second is the
  • action(s)
  • third is the
  • instance(s)
  • allow access to
  • all actions
  • all printers
  • can only leave off parts from the end of the string
  • Performance Considerations
  • runtime implication logic must execute for
  • each assigned Permission
  • implicitly using Shiro's default
  • WildcardPermission
  • which executes the necessary implication logic
  • When using permission strings like the ones shown above, you're
  • Shiro's default behavior for Realm
  • for every permission check
  • all of the permissions assigned to that user
  • need to be checked individually for implication
  • as the number of permissions assigned to a user or their roles or groups increase, the time to perform the check will necessarily increase
  • If a Realm implementor has a
  • more efficient way of checking permissions and performing this implication logic
  • Realm isPermitted* method implementations
  • should implement that as part of their
  • implies
  • user:*:12345
  • user:update:12345
  • printer
  • implies
  • printer:print
  • Implication, not Equality
  • permission
  • checks
  • are evaluated by
  • implication
  • logic - not equality checks
  • the former implies the latter
  • superset of functionality
  • implication logic can be executed at runtime
kuni katsuya

Guide to SQL Injection - OWASP - 0 views

  • Least privilege connections
  • Always use accounts with the
  • minimum privilege necessary
    • kuni katsuya
       
      yet another reason why shared db logins (eg. etl_update) are a *BAD IDEA* ie. a set of apps using the same db login are effectively granted the 'highest common denominator' of db privileges, so have more access than they should (eg. update/delete privilege on tables unrelated to app)
  • ...9 more annotations...
  • for the application
  • Parameterized Queries with Bound Parameters
  • keep the
  • query
  • d data
  • separate through the use of placeholders known as "bound" parameters
  • how to Review Code for SQL Injection Vulnerabilities.
  • Guide to SQL Injection
  • "injection" of a SQL query via the input data from the client to the application
  •  
    "Least privilege connections"
kuni katsuya

Logging JIRA SQL Queries - JIRA Development - 0 views

kuni katsuya

SQL Injection - OWASP - 0 views

  • SQL Injection
  • "injection" of a SQL query via the input data from the client to the application
  • exploit can
  • ...18 more annotations...
  • read sensitive data
  • modify database data
  • execute administration operations
  • SQL injection errors occur when:
  • Data enters a program from an
  • untrusted source
  • The data used to
  • dynamically construct a SQL query
  • consequences are:
  • Confidentiality:
  • sensitive data
  • Authentication
  • user names and passwords
  • Authorization
  • change this information
  • Integrity
  • read sensitive information
  • changes or even delete this information
kuni katsuya

Java Persistence/Inheritance - Wikibooks, open books for an open world - 0 views

  • Inheritance
  • hardest part of persisting inheritance is choosing how to represent the inheritance in the database
  • There are three inheritance strategies defined from the InheritanceType enum,
  • ...101 more annotations...
  • SINGLE_TABLE
  • TABLE_PER_CLASS
  • JOINED
  • Single table inheritance is the default
  • @MappedSuperclass
  • @Inheritance
  • mapped superclass is
  • not a persistent class
  • but allow common mappings to be define for its subclasses
  • Single Table Inheritance
    • kuni katsuya
       
      implemented as a sparse table. ie. all attributes from all entities end up as columns in the 'super' table
  • single table is used to store all of the instances of the entire inheritance hierarchy
  • table will have a column for
  • every attribute
  • every class
  • in the hierarchy
  • discriminator column
  • is used to determine which class the particular row belongs to
  • abstract
  • Project
  • extends Project
  • extends Project
  • @DiscriminatorValue("S")
  • @DiscriminatorValue("L")
  • @DiscriminatorColumn(name="PROJ_TYPE")
  • @Inheritance
  • @Table(name="PROJECT")
  • single table inheritance
  • Joined, Multiple Table Inheritance
  • mirrors the object model in the data model
  • table is defined for each class in the inheritance hierarchy to store only the local attributes of that class
  • Each table in the hierarchy must also store the object's id (primary key), which is
  • only defined in the root class
  • share the same id attribute
  • joined inheritance
  • @Inheritance(strategy=
  • InheritanceType.JOINED
  • @DiscriminatorColumn(name="PROJ_TYPE")
  • @Table(name="PROJECT")
  • abstract
  • Project
  • @DiscriminatorValue("L")
  • @Table(name=
  • "LARGEPROJECT"
  • LargeProject
  • Project
  • @DiscriminatorValue("S")
  • @Table(name=
  • "SMALLPROJECT"
  • SmallProject
  • Project
  • Table Per Class Inheritance
  • Advanced
  • table is defined for
  • each concrete class
  • in the inheritance hierarchy to store
  • all the attributes
  • of that class and
  • all of its superclasses
  • table per class inheritance
  • @Inheritance(strategy=
  • InheritanceType.TABLE_PER_CLASS
  • abstract
  • Project
  • @Table(name="LARGEPROJECT")
  • LargeProject
  • Project
  • @Table(name="SMALLPROJECT")
  • SmallProject
  • Project
  • Mapped Superclasses
  • similar to table per class inheritance, but does not allow querying, persisting, or relationships to the superclass
  • mapped superclass
  • @MappedSuperclass
  • abstract
  • Project
  • @Column(name="NAME")
  • @Table(name="LARGEPROJECT")
  • LargeProject
  • Project
  • @AttributeOverride
  • "PROJECT_NAME"
  • "name"
  • @Table("SMALLPROJECT")
  • SmallProject
  • Project
  • cannot have a relationship to a mapped superclass
  • Joined, Multiple Table Inheritance
  • oined, Multiple Table Inheritance
  • abstract
  • abstract c
  • extends Project
  • Mapped Superclasses
  • Mapped Superclasses
  • apped Superclasses
  • allows inheritance to be used in the object model, when it does not exist in the data model
  • @MappedSuperclass
  • MappedSuperclass
  • abstract
  • abstract
  • extends Project
  • extends Project
kuni katsuya

Getting Started with JSON-P (The Aquarium) - 0 views

  • JSON-P is now in the proposed final draft stage
    • kuni katsuya
       
      now == 2013.03.25
  • Getting Started with JSON-P
  • Mar 25, 2013
  • ...4 more annotations...
  • JSON-P
  • new API being added to Java EE 7
  • Java API for JSON Processing
  • API to enable developers to parse, generate, transform and query JSON, particularly in JAX-RS and WebSocket powered next-generation HTML 5 applications
kuni katsuya

How to search issues from specific Sprint - Atlassian Answers - 0 views

  • to find issues from a specific sprint, you have to add one of the following to your JQL query: 1sprint = ID 1sprint in (1,3,4)
  • have to know the ID (not name) of your sprint.
kuni katsuya

JQL Searching on the new Sprint field instead of fixVersion - JIRA Knowledge Base - Atl... - 0 views

  • Active Sprint: <sprint name>
  • sprint number is the sprintID at the end of the string
  • Sprint=<sprintID>
kuni katsuya

Advanced Searching - JIRA 5.1 - Atlassian Documentation - Confluence - 0 views

  • It is safer to search by Custom Field ID than by Custom Field nameIt is possible for a Custom Field to have the same name as a built-in JIRA system field, in which case JIRA will search on the system field (not your custom field). It is also possible for your JIRA administrator to change the name of a Custom Field, which could break any saved filters which rely on that name. Custom Field IDs, however, are unique and cannot be changed.
  • Custom Field
  • It is safer to search by filter ID than by filter nameIt is possible for a filter name to be changed, which could break a saved filter that invokes another filter by name. Filter IDs, however, are unique and cannot be changed.
  • ...3 more annotations...
  • Alias: ?cf[CustomFieldID]
  • An Advanced Searching statement in your typed query will override an ORDER BY statement in the saved filter.
  • Original Estimate
1 - 20 of 27 Next ›
Showing 20 items per page