[windows] deleting winrar temporary data

If you've ever been in the situation where you have to unzip a large archive and you cancel the unzipping process midway, you will find that upon cancellation, the temporary winrar files will not be erased so you will find yourself losing 6,7 Gb of space just like that. To fix this, go to "Run" and type %temp% - this is the temporary folder on your computer, so just go on and delete all the unused stale data (such as winrar temporary files).

Many-To-Many self reference in Java Persistence API

    Think of the following scenario: you need a many-to-many relationship between a table and itself... how can you accomplish that with JPA annotations ?
    Suppose we have a table Tasks in the database which is mapped to an Entity named Task. A task entry should have a list of parent tasks (prerequisite tasks if you want) and a list of child tasks (tasks which upon the current task's completion would enable them to start). The Task entity class would look a little something like this:

@Entity
@Table (name = "Tasks" , schema = "ProjectManagement" )
public class Task implements Serializable {

// Mandatory @Id PK field

//constructors (including a no-arg constructor)

//fields

// getters and setters


@ManyToMany
@JoinTable ( name = "parent_child_task" ,
                    joinColumns = @JoinColumn ( name = "child_id" , referencedColumnName = "id" ),
                    inverseJoinColumns = @JoinColumn ( name = "parent_id" , referencedColumnName = "id" ))
private List<Task> prerequisiteTasks = new ArrayList<Task>();

@ManyToMany (mappedBy = "prerequisiteTasks" )
private List<Task> childTasks = new ArrayList<Task>();

//.... more

}

Hope this makes sense

Operations allowed in EJB 3.0 session beans

• Operations Allowed in the Methods of a Stateful Session Bean

• Operations Allowed in the Methods of a Stateless Session Bean

SOURCE: EJB 3.0 specification

Bulk Update and Delete Operations in EJB 3.0 JPQL

Bulk update and delete operations apply to entities of a single entity class (together with its subclasses, if any). Only one entity abstract schema type may be specified in the FROM or UPDATE clause.

The syntax of these operations is as follows:
update_statement ::= update_clause [where_clause]
update_clause ::= UPDATE abstract_schema_name [[AS] identification_variable]
                            SET update_item {, update_item}*
update_item ::= [identification_variable.]{state_field | single_valued_association_field} =
                            new_value
new_value ::=
          simple_arithmetic_expression |
          string_primary |
          datetime_primary |
          boolean_primary |
          enum_primary
          simple_entity_expression |
          NULL
delete_statement ::= delete_clause [where_clause]
delete_clause ::= DELETE FROM abstract_schema_name [[AS] identification_variable]

• A delete operation only applies to entities of the specified class and its subclasses. It does not cascade to related entities.
• The new_value specified for an update operation must be compatible in type with the state-field to which it is assigned.
• Bulk update maps directly to a database update operation, bypassing optimistic locking checks. Portable applications must manually update the value of the version column, if desired, and/or manually validate the value of the version column.
• The persistence context is not synchronized with the result of the bulk update or delete.

Caution should be used when executing bulk update or delete operations because they may result in
inconsistencies between the database and the entities in the active persistence context. In general, bulk update and delete operations should only be performed within a separate transaction or at the beginning of a transaction (before entities have been accessed whose state might be affected by such operations).

SOURCE: EJB 3.0 Persistence Specification, pages 104-105

Installing XAMPP on 64 bit Ubuntu

Installing and securing XAMPP:
http://www.codetorment.com/2009/10/20/guide-install-xampp-on-ubuntu/

Basic installing:
http://sadhas.wordpress.com/2009/10/01/install-xampp-in-ubuntu/

Similar topic:
http://azimyasin.wordpress.com/2007/11/13/running-xampp-in-64-bit-machine/

How to configure Primary Key Generation in EJB 3 JPA

Introduction

TopLink may create entity identifiers (or primary keys) automatically using any of the following strategies defined by JPA:

• Sequence objects
• Identity Columns
• Tables
• Provider-assigned strategy

Usually, these generation strategies are configured locally to the primary key field or property.

Using Sequence Objects

When using a database that supports sequence objects (such as Oracle Database), you can configure JPA to use a database sequence object to automatically generate identifiers for your persistent objects.

Using A Default Sequence

TopLink JPA can produce a default sequence during schema generation. If you use schema generation, then specify that your identifier should be generated and that the SEQUENCE strategy be used to perform the generation. In the following example, the @GeneratedValue annotation indicates that the identifier value should be automatically generated; a strategy of SEQUENCE indicates that a database sequence should be used to generate the identifier. TopLink will create a default sequence object during schema generation. This object will be used by TopLink at run time.

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(strategy=GenerationType.SEQUENCE)
        private long id;

Specifying a Sequence

To use a specific named sequence object, whether it is generated by schema generation or already exists in the database, you must define a sequence generator using a @SequenceGenerator annotation. You may choose any unique label as the name for the sequence generator. Reference this name by the generator element in the @GeneratedValue annotation. Also, include the sequenceName element to specify the name of the database sequence object that you are using.

If the sequence object already exists in the database, then you must specify the allocationSize to match the INCREMENT value of the database sequence object. For example, if you have a sequence object that you defined to INCREMENT BY 5, set the allocationSize to 5 in the sequence generator definition, as the following example shows:

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(generator="InvSeq")
        @SequenceGenerator(name="InvSeq",sequenceName="INV_SEQ", allocationSize=5)
        private long id;

Using Identity Columns

When using a database that does not support sequences, but does support identity columns (such as SQL Server database), you can configure JPA to use an identity column to generate identifiers.

To enable generation of identifiers using identity columns, specify a strategy of IDENTITY. In the following example, the @GeneratedValue annotation indicates that the identifier value should be automatically generated, and the specified strategy of IDENTITY indicates that an identity column should be used to generate the identifier:

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(strategy=GenerationType.IDENTITY)
        private long id;

Using a Table

You can use a table for identifier generation on any database. It is completely portable across databases and will be automatically generated for you when schema generation is enabled.

Using A Default Table

During schema generation, TopLink JPA can generate a default table for identifier generation. If you use schema generation, then specify a strategy of TABLE in the @GeneratedValue annotation, as the following example demonstrates. TopLink will create a default table during schema generation. This table will be used by TopLink at run time:

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(strategy=GenerationType.TABLE)
        private long id;

Specifying a Table

To map to an existing table or cause the table object generated by schema generation to be given a particular name, define a table generator using a @TableGenerator annotation.

The table generator has a name, by which it is referenced in the @GeneratedValue annotation. The generator also lists the name of the specific database table, as well as the names of the key and value columns used to store identifier generators in the table. Each row in the table represents the generator for a particular entity type, with the value in the key column indicating the entity type. The generator for Inventory instances might have a key of INV_GEN, as the following example shows:

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(generator="InvTab")
        @TableGenerator(name="InvTab", table="ID_GEN",
            pkColumnName="ID_NAME", valueColumnName="ID_VAL",
            pkColumnValue="INV_GEN")
        private long id;

The table generator defined in the preceding example would be mapped to the following table:

          ID_GEN

ID_NAME	ID_VAL
INV_GEN

Using a Default Generation Strategy

By specifying a strategy of AUTO you are indicating your intention to let TopLink pick the strategy to use. Typically, TopLink picks TABLE as the strategy, since it is the most portable strategy available (it does not lock you into a particular database). However, when AUTO is specified, schema generation must be used at least once in order for the default table to be created in the database.

The following example demonstrates the use of the AUTO strategy:

@Entity
public class Inventory implements Serializable {

        @Id
        @GeneratedValue(strategy=GenerationType.AUTO)
        private long id;

Summary

The minimum configuration you can use to cause the automatic generation of identifiers is to add a @GeneratedValue annotation to the identifier field or property. If you are using a specific named database sequence or table, you need to define the generator in the metadata with @SequenceGenerator or @TableGenerator annotations.

The generation strategy that you choose to generate entity identifiers may depend on the database, on which you application is running: for instance, SEQUENCE and IDENTITY strategies are not supported on all databases.

SOURCE: http://www.oracle.com/technology/products/ias/toplink/jpa/howto/id-generation.html

JPA Inheritance mapping strategies

The mapping of class hierarchies is specified through metadata.
There are three basic strategies that are used when mapping a class or class hierarchy to a relational
database:

• a single table per class hierarchy
• a table per concrete entity class
• a strategy in which fields that are specific to a subclass are mapped to a separate table than the
•  fields that are common to the parent class, and a join is performed to instantiate the subclass.

              An implementation is required to support the single table per class hierarchy inheritance mapping strat-egy and the joined subclass strategy. Support for the table per concrete class inheritance mapping strategy is optional in this release.
              Support for the combination of inheritance strategies within a single entity inheritance hierarchy is not required by this specification.

2.1.10.1 Single Table per Class Hierarchy Strategy
         In this strategy, all the classes in a hierarchy are mapped to a single table. The table has a column that serves as a “discriminator column”, that is, a column whose value identifies the specific subclass to which the instance that is represented by the row belongs.
         This mapping strategy provides good support for polymorphic relationships between entities and for queries that range over the class hierarchy. It has the drawback, however, that it requires that the columns that correspond to state specific to the subclasses be nullable.

2.1.10.2 Table per Concrete Class Strategy
         In this mapping strategy, each class is mapped to a separate table. All properties of the class, including inherited properties, are mapped to columns of the table for the class.
         This strategy has the following drawbacks:
               • It provides poor support for polymorphic relationships.
               • It typically requires that SQL UNION queries (or a separate SQL query per subclass) be issued for queries that are intended to range over the class hierarchy.

2.1.10.3 Joined Subclass Strategy
         In the joined subclass strategy, the root of the class hierarchy is represented by a single table. Each subclass is represented by a separate table that contains those fields that are specific to the subclass (not inherited from its superclass), as well as the column(s) that represent its primary key. The primary key  column(s) of the subclass table serves as a foreign key to the primary key of the superclass table. This strategy provides support for polymorphic relationships between entities.
         It has the drawback that it requires that one or more join operations be performed to instantiate instances of a subclass. In deep class hierarchies, this may lead to unacceptable performance. Queries that range over the class hierarchy likewise require joins.


SOURCE: EJB 3.0 JPA Specification