Skip to main content

Home/ SoftwareEngineering/ Group items tagged strategy

Rss Feed Group items tagged

kuni katsuya

Chapter 5. Basic O/R Mapping - 0 views

  • 5.1.6.2. Joined subclass strategy
  • A discriminator column is not required for this mapping strategy
  •  
    "5.1.6.2. Joined subclass strategy"
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

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

[#ANN-140] Discriminator column not supported with JOINED strategy - Hibernate JIRA - 0 views

  • Hibernate does not need a discriminator
  • because Hibernate is better than these other inferior implementations
  • It is allowed for
  • ...2 more annotations...
  • inferior implementations
  • of the JOINED mapping strategy which require a discriminator
kuni katsuya

EclipseLink/Examples/JPA/Inheritance - Eclipsepedia - 0 views

  • Joined Table Inheritance
  • Annotations
  • @Inheritance(strategy=InheritanceType.JOINED) @DiscriminatorColumn(name="TYPE", discriminatorType=DiscriminatorType.STRING,length=20) @DiscriminatorValue("P")
  • ...5 more annotations...
  • @DiscriminatorValue("L")
  • Single Table Inheritance
  • Annotations
  • @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @DiscriminatorColumn(name="TYPE", discriminatorType=DiscriminatorType.STRING,length=20) @DiscriminatorValue("P")
  • @DiscriminatorValue("L")
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

Preemptive commit comments | Arialdo Martini - 0 views

  • Tell me what the software does
    • kuni katsuya
       
      tell me how the software should *behave*, not how the behavior was *implemented* ie. describe the changes in this commit from the behavioral perspective rather than implementation details
  • What is the project behavior, in this snapshot?
  • What did the programmers, in order to produce this snapshot?
  • ...43 more annotations...
  • committing comments describing the
  • behavior of the software,
  • rather than the
  • implementation or a description of what we did
  • commits’ comments started to look like BDD’s methods name: a description of a behavior.
  • principles
  • Talk about the feature, not about yourself
  • Don’t refer to the past
  • I know it’s now
  • list of benefits
  • More focus while developing
  • Commit review is much easier
  • Less cognitive load
  • You learn commenting much more precisely
  • commit comment becomes a
  • declaration of intent
  • like a BDD method name
  • No more “Just a fix“, “Improvements” or “I made this, this, this and also this” comments.
    • kuni katsuya
       
      BDD/TDD or any methodology aside, these are the worst commit comments as they are as useless as empty commit comments
  • Each preemptive comment triggers a micro design session
  • A preemptive comment sets a micro goal
    • kuni katsuya
       
      which also aligns well with the 'micro goal' or incremental deliverables approaches of most agile methodologies 
  • helps to focus a goal to be reached
  • Without preemptive comments, I often went on coding, always asking myself: “Should I commit now? Have I reached a stable state which I could consider a good commit?“
  • define micro-goals through preemptive comments
  • macro-goal through the feature branch name
  • A preemptive comment creates a little timebox
    • kuni katsuya
       
      similar to the timeboxing strategy of a short sprints, for instance
  • Writing comments preemptively puts the agreement between the pair members to a test
    • kuni katsuya
       
      more relevant to methodologies using pair programming
  • commit history gains a very balanced granularity
  • feature branch becomes a collection of evolutionary commits each of which has usually a 1:1 binding with tests
  • very easy to find which commit introduced a bug, since each commit is related to a single new goal/feature
  • Preemptive commit comments
  • Rule #2: write what the software
  • I started taking a lot of care of the words I was using in comments, commits, test names and classes/variables/methods’ names
  • be supposed to do,
  • not what you did
  • should
  • Introducing BDD
  • began with the simple attempt to replace the world
  • “should“
  • “test”
  • with the world
  • Rule #1: write commit comments before coding
  • use the same criteria for my commits’ comments as well.
  • (not what you did)
kuni katsuya

Domain Language /Newsletter - 0 views

  • Getting Started with DDD When Surrounded by Legacy Systems II
  • Strategy 2: Autonomous Bubble
kuni katsuya

Equals and HashCode | Hibernate | JBoss Community - 0 views

  • best strategies for implementation of equals() and hashcode() in your persistent classes
  • The general contract is: if you want to store an object in a List, Map or a Set then it is an requirement that equals and hashCode are implemented so they obey the standard contract as specified in the  documentation
  • Why are equals() and hashcode() importantNormally, most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
  • ...8 more annotations...
  • Separating object id and business key
  • recommend using the "semi"-unique attributes of your persistent class to implement equals() (and hashCode()
  • The database identifier property should only be an object identifier, and basically should be used by Hibernate only
  • Instead of using the database identifier for the equality comparison, you should use a set of properties for equals() that identify your individual objects
  • "name" String and "created" Date, I can use both to implement a good equals() method
  • Workaround by forcing a save/flush
  • work around by forcing a save() / flush() after object creation and before insertion into the set
  • Note that it's highly inefficient and thus not recommended
kuni katsuya

12 Tips On JPA Domain Modelling - With Existing Database - Thinking In Structs Not Obje... - 0 views

  • think in structs. Try to as frictionless as possible export/generate the JPA-entities from the existing database
  • Implement a very thin facade / transaction boundary
  • @Stateless Bean (EJB 3)
  • ...10 more annotations...
  • If the JPA entities still do not look right, try to apply some JPA tricks like mapping a JPA-entity to several tables, or even map JPA-entities to DB-views, to improve the situation
  • Rename the classes into some more meaningful. The attribute, class names are in general everything but not fluent
  • Junit. Purpose: JPA mapping verification
  • Thinking In Structs Not Objects
  • 12 Tips On JPA Domain Modelling
  • - With Existing Database -
    • kuni katsuya
       
      strategy when constrained by baggage of *legacy database* schema, NOT for a green fields project!
  • Execute the "Unit" tests after every change
  • even better get rid of them
  • domain objects are
  • semi-objectoriented
kuni katsuya

15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfie... - 0 views

  • [For Greenfields]
  • Try to identify concepts and abstractions from the target domain. Use them as candidates for entities.
  • Do not obfuscate them with additional technical naming conventions like XYZEntity or "BOs".
  • ...10 more annotations...
  • Write unit tests
  • without involving the EntityManager
  • - Thinking In Objects
  • JPA Rich Domain Modelling
    • kuni katsuya
       
      strategy to use when less or unconstrained by legacy db schema baggage. ie. the *proper* and *ideal* way to model domain classes... using oo, not dumb structs!  :)
  • Build objects, not structs
  • Think about builders
  • Let the tool (JPA-provider) generate the DDL
    • kuni katsuya
       
      generated ddl can be optimized by hand if required
    • kuni katsuya
       
      eg. see step 12 below
  • Provide a lean facade/service layer
  • only contain crosscutting concerns
kuni katsuya

How To Deal With Interfaces In Java EE 6 (or no more Impl) : Adam Bien's Weblog - 0 views

  • How To Deal With Interfaces In Java EE 6 (or no more Impl)
  • In Java EE 6 interfaces became absolutely optional. Neither in EJB 3.1, nor CDI / JSR-330 you need interfaces. You can inject classes directly. They will be still proxied, so all aspects like persistence, transactions, interceptors, decorators are still available. So you are no more forced to implement interfaces by the container
  • used for: Strategy Pattern: there are already several implementations of an algorithm or concept Layering: there is a clear need to hide e.g. an ugly implementation of a legacy framework API (not very common): you have to expose a API, which gets implemented by SPI (e.g. JDBC)
  • ...4 more annotations...
  • If you introduce interfaces intentionally - and not as a general rule, you will considerably reduce the number of files. Your code becomes easier to understand and so maintain
  • Even for decoupling purposes, interfaces are no more needed
  • "Contract First", "Coding To Interfaces" or "Decoupling"
  • is not a reason to introduce an interface for everything
kuni katsuya

Authentication Cheat Sheet - OWASP - 0 views

  • Authentication Cheat Sheet
  • Sessions should be
  • unique per user
  • ...26 more annotations...
  • computationally very difficult to predict
  • "strong" password policy
  • Secure Password Recovery Mechanism
  • Require re-authentication for Sensitive Features
  • Authentication and Error Messages
  • can be used for the purposes of user ID and password enumeration
  • Incorrectly implemented error messages
  • generic manner
  • respond with a generic error message regardless if the user ID or password was incorrect
  • give no indication to the status of an existing account
  • Authentication responses
  • Invalid user ID or password"
  • does not indicate if the user ID or password is the incorrect parameter
  • Transmit Passwords Only Over TLS
  • login page
  • all subsequent authenticated pages
  • must be exclusively accessed over TLS
  • unencrypted session ID
  • credentials
  • Implement Account Lockout
  • lock out an account if more than a preset number of unsuccessful login attempts are made
  • can produce a result that locks out entire blocks of application users accounts
    • kuni katsuya
       
      somewhat of a denial-of-service attack, since legitimate users can no longer access their accounts/services
  • sensible strategy
  • is to lockout accounts for a number of hours
  • Password lockout mechanisms have a logical weakness
  • Session Management General Guidelines
1 - 20 of 21 Next ›
Showing 20 items per page