Skip to main content

Home/ Groups/ SoftwareEngineering
Rss Feed
Sort By: Most Recent | Popular Filter: All | Bookmarks | Topics Simple Middle
5More

Persistence - Arquillian - Project Documentation Editor - 0 views

docs.jboss.org/...Persistence jpa testing arquillian
shared by kuni katsuya on 03 Jul 12 - No Cached
  • Seeding database
  • Arquillian Persistence Extension is created to help you writing tests where persistence layer is involved
  • Comparing database state at the end of the test using given data sets
  • ...2 more annotations...
  •  @UsingDataSet("datasets/users.yml")
  •    @ShouldMatchDataSet("datasets/expected-users.yml")
25More

Entity-attribute-value model - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/...Entity-attribute-value_model eav sparse open schema
shared by kuni katsuya on 01 Jul 12 - Cached
  • Entity–attribute–value model
  • Entity–attribute–value model (EAV) is a data model to describe entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest
  • also known as object–attribute–value model, vertical database model and open schema
  • ...21 more annotations...
  • In an EAV data model, each attribute-value pair is a fact describing an entity, and a row in an EAV table stores a single fact
  • EAV tables are often described as "long and skinny": "long" refers to the number of rows, "skinny" to the few columns
  • Data is recorded as three columns: The entity: the item being described. The attribute or parameter: a foreign key into a table of attribute definitions. At the very least, the attribute definitions table would contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation
  • The value of the attribute
  • Row modeling, where facts about something (in this case, a sales transaction) are recorded as multiple rows rather than multiple columns
  • differences between row modeling and EAV (which may be considered a generalization of row-modeling) are:
  • A row-modeled table is homogeneous in the facts that it describes
  • The data type of the value column/s in a row-modeled table is pre-determined by the nature of the facts it records. By contrast, in an EAV table, the conceptual data type of a value in a particular row depend on the attribute in that row
  • In the EAV table itself, this is just an attribute ID, a foreign key into an Attribute Definitions table
  • The Attribute
  • The Value
  • Coercing all values into strings
  • larger systems use separate EAV tables for each data type (including binary large objects, "BLOBS"), with the metadata for a given attribute identifying the EAV table in which its data will be stored
  • Where an EAV system is implemented through RDF, the RDF Schema language may conveniently be used to express such metadata
  • access to metadata must be restricted, and an audit trail of accesses and changes put into place to deal with situations where multiple individuals have metadata access
  • quality of the annotation and documentation within the metadata (i.e., the narrative/explanatory text in the descriptive columns of the metadata sub-schema) must be much higher, in order to facilitate understanding by various members of the development team.
  • Attribute metadata
  • Validation metadata include data type, range of permissible values or membership in a set of values, regular expression match, default value, and whether the value is permitted to be null
    • kuni katsuya
      kuni katsuya on 01 Jul 12
       
      jsr-299 bean validation anyone?  :)
  • Presentation metadata: how the attribute is to be displayed to the user
  • Grouping metadata: Attributes are typically presented as part of a higher-order group, e.g., a specialty-specific form. Grouping metadata includes information such as the order in which attributes are presented
  • Advanced validation metadata Dependency metadata:
2More

Why Not Private Visibility For Injected Fields [Screencast] : Adam Bien's Weblog - 0 views

www.adam-bien.com/...why_not_private_visibility_for package visibility javaee6
shared by kuni katsuya on 03 Jul 12 - No Cached
  • Why Not Private Visibility For Injected Fields
  • Package visibility for injected fields encapsulates way better than public accessors and makes unit testing more convenient at the same time
7More

Article Series: Migrating Spring Applications to Java EE 6 - Part 3 | How to JBoss - 0 views

howtojboss.com/...rom-spring-to-java-ee-6-part-3 spring javaee6 migration
shared by kuni katsuya on 02 Jul 12 - No Cached
  • Stateless Session Bean is transactional by default
  • In this article we will discuss migrating the DAO layer, AOP and JMX
  • Migrating JDBC templates
  • ...3 more annotations...
  • In general, JDBC Templates are a poor solution. They don’t have enough abstraction to work on different databases because you use plain SQL in queries. There is also no real ORM mapping which results in quite a lot of boilerplate code
  • SimpleJdbcTemplate(ds)
  • @InterceptorBinding
  • kuni katsuya on 02 Jul 12
     
    Stateless Session Bean is transactional by default.
6More

Migrating from Spring to Java EE 6 - Part 4 | How to JBoss - 0 views

howtojboss.com/...rom-spring-to-java-ee-6-part-4
shared by kuni katsuya on 02 Jul 12 - No Cached
  • discuss the rationale for migrating your applications from Spring to Java EE 6 and show you real examples of upgrading the web UI, replacing the data access layer, migrating AOP to CDI interceptors, migrating JMX, how to deal with JDBC templates, and as an added bonus will demonstrate how to perform integration tests of you Java EE 6 application using Arquillian
  • EntityManagerClinicTest
  • There is also an interesting Arquillian Persistence extension that integrates DBUnit in Arquillian where you can define your test data externally
  • ...3 more annotations...
  • @RunWith(Arquillian.class)
  • JDBC Templates hardly give any abstraction on top of the database and you’re on your own for Object Relational Mapping. We strongly advise to use JPA wherever possible; it gives portability by abstracting most of the database specific SQL that you would need, and it does all the hard and painful work of object mapping
  • small part of your application
« First ‹ Previous 961 - 980 of 1272 Next › Last »
Showing 20▼ items per page