Hibernate and deleting persistent objects:
When deleting objects with Hibernate it's best to think of it as making an object transient. The state of the object is erased from the database but it can be referenced.  The order of deleting the objects is not important because there is no risk of violating a foreign key constraint. A NOT NULL constraint on a foreign key column may still be violated if the order is incorrect.--
This is resolved by cascade options.
When flushing the session, the following order is important
All entity insertions in the same order that the save () were called
All entity updates
All collection deletions
All collection elements deletions, updates and insertions.
All collection insertions
All entity deletions in the same order as delete () were called.
While this order is guaranteed there are no guarantees when these JDBC calls will be called except unless explicitly invoked with a flush(). That said, there are different FlushModes available to make these less frequent.
These modes include :
- flush at commit time when the Hibernate Transaction API is used
- flush automatically using the explained routine
- or never flush unless flush is explicitly called.
In addition to Flush modes and cascade styles offered, Hibernate also makes its metadata available to applications. This way applications can choose to implement deep copy algorithms such as for mutable value types and not for immutables or associated entities. Hibernate exposes metadata via the SessionFactory. Instances of the metadata interfaces include ClassMetadata, CollectionMetadata, and the Type hierarchy.

Persisting objects with Hibernate.
Hibernate defines three object states. Transient, persistent and detached
Transient state is for example a new object. It has no ID associated and consequently no representation in the database. These objects will be collected by the garbage collector. The session helper methods can be used to save the object.
A persistent state is one where there is a database representation available. When we load an object we put it in this state. This object is now in the scope of session. Any changes made to the object will be detected.
A detached state is one where the object goes out of scope of session. Changes can be made because the reference is valid. When the object is reattached to a session,  it and all  it's changes can become persistent again. This enables a way to work with long running unit if work which are called application transaction.
The save method on the session makes an object persistent. It does not guarantee to return an identifier. The assignment might happen at flush time.
The load method of a Session provides a way of retrieving a persistent instance based on its identifier.
Load can work through a proxy. If the class is mapped with a proxy, load returns an initialized proxy which does not actually hit the database. This helps with creating associations or working with batches. If the load has to reach a database and there is no matching row, then there is an unrecoverable exception.Its better to detect the database record with a get method which returns null if there's none. Objects can be loaded for update only when there's a LockMode specified or a cascade style specified.
Reload of an object can work with refresh in the sequence save()->flush()->refresh()
Objects saved by the session are all transactional persistent instances and any changes to the persistent state will be persisted when the session is flushed. Therefore there is no need to call a method such as update between load and flush.
Hibernate works with states only. It does not work with SQL statements from users. That approach might be better with JDBC. Further Batch processing conflicts with online transaction processing, so prefer not to do batching with Hibernate although some options are available.
When an object is loaded but presented to a higher layer where it may spend an inordinate amount of time may require separate transactions for the retrieving and saving. These "long" unit of work therefore have to work with versioned data.
To reattach this detached instance, we call update if the session does not already contain a  persistent instance. We use merge when we want to merge the modifications at any time without consideration of the state of the session.

If there are associated items to the entity we want to save, then they too can be persisted in any order as long as there is no not null constraints on a foreign key column. There is never a risk of violating a foreign key constraint. On the other hand there is risk of violating a not Null foreign constraint if the order is not maintained.

As an aside, the lock method can be used to reassociate a detached object. However the detached instance has to be unmodified. There are several LockMode available.

We now look at automatic state detection. This is enabled via saveOrUpdate method.
This method is supposed to generate a new identifier or reattach with an existing identifier. But first let's note that update, merge and saveOrUpdate methods are not to be called if we are using the same session. They are typically used when going from older session to a newer session.

SaveOrUpdate uses object versioning either with a version or a timestamp. If the version is the same, save it. If the version is different update it

Merge is very different. If there is a persistent entity with the same identifier in the session,  merge will  update it. If there is no persistent entity, merge will load from the database or create a new one. The returned entity doesn't become part of the session but remains detached.

#codingexercise


GetAllNumberRangeProductNinthRootPowerTen(Double [] A)



{





if (A == null) return 0;





Return A.AllNumberRangeProductNinthRootPowerTen();


}

In continuation of our discussion on an example of Graph API, shall we look into a generic methods of graph related computing. Take for example, persistence of a graph by reachability. How do we find nodes in the graph that correspond to entities that should be affected when a start node or a pivot entity is to be modified and saved? These are  done witg shared references. We find that shared references prevents us from deleting an entity even when the pivot entity is being deleted simply because another entity is using the shared reference
 If all the nodes are connected by a root entity, meaning all entities derive from a root object type, does it help to have a process that can find and collect these dirty elements. Taking it more generally give a connected graph where there are entities constantly getting dirtied, how do we non-invasively differentiate them and connect a subgraph that we need to work on ?

One such method to deal with this is the garbage collection method using gossip algorithm from the text book. Here is an example:

We first need to find the dirty objects in the graph. There are two processes involved - a marker process that marks different objects as dirty/clean and a mutator process that is responsible for connecting nodes that are already in sync with the store and need not be taken any action on. 

The marker need not be exact. It can be conservative. 

The mutator and the marker do not interfere with each others running because they work on basis of superposition. That is they touch data that are not related to each other. 

We begin with the root and simply mark vertices that can be reached from the already marked ones. This behaves just like the gossip program. However, the mutator can still frustrate the marker. So we add a second logic to say that we add an edge to x,y when y is clean and set both x and y to delete, we delete an edge between x and y when either of them is false. This way we build the sub-graph we are interested in.

In today's post we will be reviewing the Open Graph protocol as described online. We will review what's mentioned on the web and then we will explore some from their GitHub.  Graphs provide a very intuitive and wholesome representation of the data such as in web pages particularly social media such as Facebook. Its not that relational, no-sql or object databases don't serve as a good store for the computations of the social media, they don't simply provide a single technology for a developers to interact with. Consequently the graph protocol and its API enters the picture. By converting the data in the web pages and the social accounts into a graph, we can enable more such functionalities as multiple posts and multiple comments. The relationship between the graph objects allows us to do CRUD operations on these objects.
Facebook Graph API comprises of the following:
1) nodes - these pertain to resources such as a User or a Photo, a page or a Comment
2) edges - the connections between those resources such as a Page's photos or a Page's comments.
3) fields - the things such as the birthday of the User
The Graph API is HTTP based and follow the REST paradigm and conventions. For Example, GET /me will return your profile information. APIs are available are comprehensive and distributed into core and extended set of APIs. APIs are also authorized and require an access_token.
Subsequently the objects were versioned with /v2.1/{object}
Core API's and SDKs are central to the Facebook Platform. These elements are subject to a version system and gurantee that anything considered a code API node, field, edge dialog, SDK or SDK method will remain unavailable and unchanged for a span of two years from the version release.  Breaking changes come via new version.
Core Elements include Facebook login, share dialog, requests dialog, the like button, the Facebook SDK for iOS, the Facebook SDK for Android, some methods of the Facebook SDK for JavaScript and Some Graph API fields and endpoints.
Extended is everything beyond that, APIs and SDKs.  The extended are subject to variation within 90 days.
APIs can be simply read-based. In addition, we can choose fields to make a query.
Objects can also be discovered by their IDs. But sometimes this is not possible. In such cases, we can use the URL node to return the IDs of Open Graph Object URLs or find data associated with an App Link URL.  We can even retrieve multiple objects with object type such as
GET /me/{action-type}/{object-type}
App Link URLs take the form :
GET graph.facebook.com?ids=http://fb.me/<id>/&fields=app_links&access_token=<access_token>

While we continue our discussion on Graph API of Facebook, we can also take a look at some of the simple Graph methods as implemented here:

https://github.com/ravibeta/csharpexamples/tree/master/CodingExercises/CodingExercises
And how graph apis work at :  http://1drv.ms/1PxFU

Coming back to our discussion on FaceBook Graph API, let's us explain the App Link a bit more since it's a FaceBook concept and not a general concept we have been discussing so far. App Links enables deep link to content in our Facebook app. With this kind of sharing it is possible to jump to and from the Facebook application to the App Links App. Moreover the content is brought into the Facebook App. It works by adding metadata to existing URLs on the web so that they can be consumed by our Facebook App. 

Today  we wrap your discussion on DBPowder. We saw the ORM framework and it's processes. We saw the flexibility  for both simple and complex correspondences. We saw the use of Active record for data wrapper and data classes. When the developer describes the eer model, the relation classes and ObjectView are generated. In this case the process kicks off by mapping tables to entities with a one to one  mapping. The attributes of the conceptual model become attributes of the table and the entities. Then the relationships are established and their cardinality is specified. With the help of this information from the conceptual model we can then add the biderctional attributes to tables and classes. Sometimes it is easier to ease the relationship into a new entity and this is one of the flexibility offered by DBPowder in its code generation. For examples a user table having many different users  registering different hosts has many registration dates that cannot be attributes in the user or hosts table . Next we add hierarchy information and this is possible in one of three different ways.
The complex correspondences are described using the ObjectView where a graph based object is used to generate the cpc equivalences in complex correspondences with rs. This ObjectView takes application logic into account as well. A pivot entity is chosen which is the starting point,  connectivity for the edges are established along with that of the relationship and cardinality set. The nodes and edges for a hierarchy are defined along with a direction from parent entity to child entity. Then the nodes within the subgraph of the directed graph which have one-connectivity are combined to form a group.  Class definitions are generated from the grouped node.
The code generator generates the source code for the relational schema with the relational tables so far and their corresponding simple persistent classes for the simple correspondences. It also generates the source code for the complex persistent classes with the eer and the specific object views. With the help of ActiveRecords, we move away from many to many correspondences between persistent classes and tables to one to one correspondences between ActiveRecords and tables.

#codingexercise

GetAllNumberRangeProductSeventhRootPowerTen(Double [] A)


{




if (A == null) return 0;




Return A.AllNumberRangeProductSeventhRootPowerTen();



}

Today we continue our discussion on DB powder. Using DBPowder and ObjectView, developers can come up with a number of persistent classes along with each part of the application logic. In this case, a table might be used by more than one persistent class. There are many to many correspondences among persistent classes and tables and the persistent classes hold the values. Now if there are persistent objects in the same session, and they hold the same attribute value, in the same tuple, they cannot recognize each other that the attribute value is the same.  To solve this issue, DBPowder leverages ActiveRecord. The data wrapper classes and the data classes access tables using ActiveRecords. Because values of data wrappers are held in ActiveRecords and each of the data wrapper is the wrapper class of the Active Records,values in data wrapper can have a single correspondence with those in the tables. As a result, each persistent class can recognize each other that the attribute value is the same.
We now look at a Prototype system of DBPowder and a production use. The first version of the prototype system for DBPowder was implemented in JavaSE in  2006. In this paper, EER model and ObjectView support were added. The prototype included a description language, DBPowder-mdl and has a parser and code generator to interpret DBPowder-mdl and generate source code.  The prototype also generates simple web pages for create, retrieve, update and delete operations. DBPowder-mdl, the parser and the GEN were refined in this paper.
The set of web applications and the DBPowder system was applied in production for the security administration task and refined. The same set of applications were deployed to another site where the number of users in two sites were 130.

Today we continue the discussion on DB-Powder  description language - the DBPowder mdl.  The goal of this language is to allow developers to describe the conceptual model. As we have seen in the previous posts, that DBPowder uses a process to generate code and tables with this model. The description style of DBPowder-mdl is either EER-style or Object-View style. The EER style primitives are Entity E, Attribute A and linked-entity L.  The primitives are described in hierarchical structure.  Primary keys can be omitted because DBPowder assigns surrogate keys.
To extend the hierarchical structure into a graph, E and L can be described more than once. We saw that generalization hierarchies are supported by  Single Relation (SR), Class Relation Inheritance (CR), and Concrete Class Relation Inheritance (CCR).
The Object-View style primitives are the pivot-entity PE and the member-entity ME.
The code generation generates the source code using the EER model or the Object View. Developers add application codes using the generated class and built-in session class. The code generator represents the EER, Object View and the ORM processes and this helps to generate the relational schema and persistent classes. The latter include data wrapper class, logic class and a session class. A sample usage of the application codes involves developers to hold the values in the data wrappers using the getter/setter methods and then presist the values into session classes using CRUD methods such as insert, find, update delete etc. This is achieved because the data classes are using ActiveRecords and the data wrapper has correspondence with tables via the ActiveRecords.
#codingexercise



GetAllNumberRangeSumSeventhRootPowerTen(Double [] A)



{



if (A == null) return 0;



Return A.AllNumberRangeSumSeventhRootPowerTen();


}