Skip to main content

Home/ SoftwareEngineering/ Contents contributed and discussions participated by kuni katsuya

Contents contributed and discussions participated by kuni katsuya

kuni katsuya

Refactoring Databases - Evolutionary Database Design - 1 views

  • Evolutionary Database Design
  • Refactoring Databases : Evolutionary Database Design
  • Recipes for Continuous Database Integration
kuni katsuya

Selling Weld and EE6 | Weld | JBoss Community - 0 views

  • regarding the issue of selling Weld and EE6 to developers/shops....
  • How bout a JdbcTemplate Spring equivalent in the case of projects using legacy db schemas
  • portable extension to Weld
  • ...32 more annotations...
  • William Drai
  • Honestly I don't see any value in switching to CDI if it is
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Gavin King
  • Their template pattern is a solution in search of a problem
    • kuni katsuya
       
      gold! :)
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.
  • This is exactly the kind of
  • brain-damage that Spring does to people!
    • kuni katsuya
       
      platinum!!!
  • It gives people a
  • half-assed solution
  • and somehow shuts down their brains so they
  • stop asking themselves how this solution could be improved upon
  • It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.
  • but that might be too high-level for your taste. Their are other, less-abstract options.
  • exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."
  • Utter nonsense and dishonest false advertising
  • Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.
  • Pffffff. It's a trivial requirement which I can solve in my framework with two lines of code in a @Disposes method. Did you see any connection handling in the code above?
  • I mean, seriously guys. The Spring stuff is trivial and not even very elegant. I guess it's easier for me to see that, since I spent half my career thinking about data access and designing data access APIs. But even so...
  • I don't understand. You hate the ability to write typesafw SQL that much?
  • Gavin King
  • Methods with long argument lists are a code smell.
  • It's something Spring copied from Hibernate 1.x, back in the days before varargs
  • It's something we removed in Hibernate2 and JPA.
  • there are a bunch of people
  • who don't want to use JPA.
  • They don't understand, or see the value of, using managed objects to represent their persistent data.
  • Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?
  • Are you working from some totally bizarre metric where you measure code quality by number of classes?
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

mysql - Relationship between catalog, schema, user, and database instance - Stack Overflow - 0 views

kuni katsuya

MySQL :: Enforcing Foreign Keys Programmatically in MySQL - 0 views

  • programmatically enforce foreign keys on storage engines which do not natively support them
  • done by the use of triggers
  • Enforcing Foreign Keys Programmatically in MySQL
  •  
    "UPDATE myisam_parent SET mparent_id=4 WHERE mparent_id=3; "
kuni katsuya

MySQL Error Number 1005 Can't create table '.mydb#sql-328_45.frm' (errno: 150) | VerySi... - 0 views

  • MySQL Error Number 1005 Can’t create table
  • (errno: 150)
  • SHOW ENGINE INNODB STATUS
  • ...12 more annotations...
  • Known Causes:
  • First Steps:
  • dreaded errno 150:
  • The two key fields type and/or size is not an exact match
  • One of the key field that you are trying to reference does not have an index and/or is not a primary key
  • One or both of your tables is a MyISAM table
  • You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL
  • Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns
  • You have a default value (ie default=0) on your foreign key column
  • You have a syntax error in your ALTER statement or you have mistyped one of the field names in the relationship
  • The name of your foreign key exceeds the
  • max length of 64 chars
    • kuni katsuya
       
      64 char max? seriously??? in this century?!
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

AllPermission (Apache Shiro 1.2.1 API) - 0 views

  • AllPermission
  • always implies any other permission
    • kuni katsuya
       
      equivalent to *:*, ie. all actions on all resource types
  • implies method
  • ...2 more annotations...
  • always returns true
  • have the ability to do anything
kuni katsuya

RolePermissionResolver (Apache Shiro 1.2.1 API) - 0 views

  • RolePermissionResolver
  • resolves a String value and converts it into a Collection of Permission instances
  •  Collection<Permission> resolvePermissionsInRole(String roleString)
  • ...2 more annotations...
  • role name to resolve
  • Collection of Permissions
kuni katsuya

Subject | Apache Shiro - 0 views

  • Understanding Subjects in Apache Shiro
  • 'Subject'
  • is just a security term that means a
  • ...8 more annotations...
  • security-specific 'view'
  • of an application user
  • Subject instance represents both security state and operations for
  • a single application user
  • in the security world, the term 'Subject' is actually the recognized nomenclature
  • Subject currentUser = SecurityUtils.getSubject();
  • obtain the currently executing Subject by using org.apache.shiro.SecurityUtils:
  • Subject based on user data associated with current thread or incoming request.
kuni katsuya

Testing | Apache Shiro - 0 views

  • Testing with Apache Shiro
  • how to enable Shiro in unit tests.
  • Subject
  • ...14 more annotations...
  • is security-specific view of the
  • 'currently executing' user
  • and that Subject instances are always bound to a thread to ensure we know who is executing logic at any time during the thread's execution
  • Subject instance must be created
  • Subject instance must be bound to the currently executing thread
  • Subject must be unbound to ensure that the thread remains 'clean' in any thread-pooled environment
  • Shiro has architectural components that perform this bind/unbind logic automatically
  • root Shiro Filter performs this logic when filtering a request
  • after creating a Subject instance, it must be bound to thread
  • Test Setup
  • 'setup' and 'teardown'
  • can be used in both unit testing and integration testing
  • AbstractShiroTest
  • abstract class AbstractShiroTest
kuni katsuya

Java EE Revisits Design Patterns: Asynchronous - Java Code Geeks - 0 views

  • Java EE Revisits Design Patterns: Asynchronous
  • @Asynchronous
  • tell the JavaEE container to run the called method in a separate thread asynchronously
  • ...5 more annotations...
  • @Asynchronous
  • @Asynchronous
  • Future<>
  • simple to use
  • as a return type and to receive a result asynchronously
« First ‹ Previous 441 - 460 of 1268 Next › Last »
Showing 20 items per page