Skip to main content

Home/ SoftwareEngineering/ Group items tagged hierarchy

Rss Feed Group items tagged

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

Inheritance and custom types (Hibernate) - 1 views

  • Choosing a strategy
  • You can apply all mapping strategies to abstract classes
  • and interfaces
  • ...8 more annotations...
  • Interfaces may have no state but may contain accessor method declarations, so they can be treated like abstract classes
  • Inheritance and custom types (Hibernate)
  • Mapping class inheritance
  • four different approaches to representing an inheritance hierarchy:
  • Table per concrete class with implicit polymorphism
  • Table per concrete class
  • Table per class hierarchy—
  • Table per subclass
kuni katsuya

Managing Project Permissions - JIRA 5.1 - Atlassian Documentation - Confluence - 0 views

  • Project permissions can be granted to:
  • Individual usersGroupsProject rolesIssue roles such as 'Reporter', 'Project Lead' and 'Current Assignee''Anyone' (e.g. to allow anonymous access)A (multi-)user picker custom field.A (multi-)group picker custom field. This can either be an actual group picker custom field, or a (multi-)select-list whose values are group names.
  • Many other permissions are dependent on this permission
    • kuni katsuya
       
      example of dependencies *between* permissions. eg, in this case, work-on-issues permission 'needs' browse-projects permission could be expressed as a permission hierarchy where if work-on-issues permission is granted, means/implies that user already has browse-projects permission (w-o-i perm 'subsumes' b-p perm) might imply permission hierarchy
  • ...8 more annotations...
  • Permission Schemes
  • A permission scheme is a set of
  • user/group/role
  • assignments for the project permissions
  • Every project has a permission scheme
  • One permission scheme can be associated with multiple projects
  • Permission schemes prevent having to set up permissions individually for every project
  • it can be applied to all projects that have the same type of access requirements
kuni katsuya

Java API Design Checklist « The Amiable API - 0 views

  • Java API Design Checklist
  • Do not use
  • marketing
  • ...18 more annotations...
  • project
  • organizational
  • names
  • Do not move or rename the package of an
  • already released public API
  • Begin with a short, one sentence summary of the API
  • Provide enough details
  • Include the API version number
  • Ensure each type has a single, well-defined purpose
  • Type Design Checklist
  • Ensure types represent domain concepts, not design abstractions
  • Follow consistent design patterns when designing related types
  • Favor enumeration types over constants
  • Consider generic types
  • Avoid deep inheritance hierarchies
  • Do not use public nested types
  • Do not declare public or protected fields
  • Do not expose implementation inheritance to the client
kuni katsuya

DataNucleus Access Platform - JPA Inheritance - 0 views

  • DataNucleus AccessPlatform 3.1 Documentation
  • JPA : Inheritance Strategies
  • JOINED
  • ...2 more annotations...
  • "JOINED" strategy
  • each entity in the inheritance hierarchy has its own table and that the table of each class only contains columns for that class
kuni katsuya

Advanced entity association mappings (Hibernate) - 0 views

  • Ternary associations
  • Figure 7.12 A ternary association with a join table between three entities
  • Polymorphic associations
  • ...11 more annotations...
  • Polymorphic many-to-one associations
  • Polymorphic collections
  • Polymorphic associations to unions
  • Polymorphic table per concrete class
  • Fully polymorphic behavior is available, but there is no annotation support for any mappings.
  • Hibernate supports fully polymorphic behavior. It provides extra support for any association mappings to an inheritance hierarchy mapped with implicit polymorphism.
  • Hibernate Core
  • Table 7.1 Hibernate and JPA comparison chart
  • Java Persistence and EJB 3.0
  • Advanced entity association mappings (Hibernate)
  • Mapping maps
kuni katsuya

Grails - user - Can Spring Security OR Shiro Enable Fine Grained Hierarchical Permissions? - 0 views

  • one option would be to embed the hierarchy of locations in the permission strings
  • since you can have any number of elements separated by colons
  • Another option would be to create your own Permission instances and implement the isPermitted() method such that it delegates to Location.isIn(Location) for permission checks
  • ...2 more annotations...
  • associate permissions with a particular domain instance AND all children of that instance.
  • associate a single rule/ACL Entry that says Sally has full hierarchical permission over France
kuni katsuya

Securing Data Access - 0 views

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?
1 - 10 of 10
Showing 20 items per page