Represent Java beans as links

[GoogleCodeExporter]

Java beans are represented as record structures where the slots are part of 
the value of an atom.

An alternative is to represent Java beans as link b/w slots. This is not 
necessarily better because it precludes a bean from being a link 
independently from its record structure. Or simply the slot values may not 
have to become atoms and be linked etc. It all depends on the 
representation needs. But we should have a JavaObjectMapper that creates 
Java bean types based on that idea. The mapper could reverse to the current 
mapping is the Java class implements HGLink.

Also, we might want another Java annotation, perhaps at the class level 
that explicitly asks for this (e.g. HGRecordLink) and/or at the field level 
(e.g. HGLinkTarget), so as to allow maximum flexibility in how beans are 
represented. The HGLinkTarget annotation could work with classes 
implementing HGLink to selectively represent some of the fields as link 
targets and others as part of the record value structure.

Original issue reported on code.google.com by borislav...@gmail.com on 13 Jan 2010 at 3:19

[GoogleCodeExporter]

Original comment by borislav...@gmail.com on 20 Jan 2010 at 5:03

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

It would be even more valuable to reduce API intrusion if Java classes didn't 
have to implement the HGLink interface. This would work if their type provided 
the HGLink operations. However, by default it is not cheap to get the type of 
an atom (unless it implements the HGTypeHolder interface). So a solution could 
be to store it in the HGLiveHandle, either as a variant implementation or by 
default. If it's stored by default, we increase memory consumption 
significantly and we deprecate HGTypeHolder, but certain operation will be 
significantly faster (e.g. in traversals when filtering by type etc.) - though 
decision.

Original comment by borislav...@gmail.com on 2 Oct 2010 at 6:21

[GoogleCodeExporter]

If I get you correctly, this way be another db4o implementation.
In deed, I did a try for java type system, just no storage, but more complicate 
than both. because I hope give user more free to choice it's type mapping. I 
failed.
in 2008 I try to use db4o, when i dive into it, i dispear:) the type system not 
so brialnt, in some place, even not coverd my try.
I think I should get my try to complete.

Original comment by saintof...@gmail.com on 13 Mar 2011 at 8:39

[GoogleCodeExporter]

Here are some ideas on possible annotations that would define the mapping:

public class Person
{
   // stored as right now, part of a record value structure.
   private String name;

   // Make Person into a link whose first target will be an atom
holding the address
  @TargetAt(0)
   private Address address;

   // Second target will be the organization employing the person
   @TargetAt(1)
   private Organization employer;

   // Link this atom as the first target of a link labeled "mother"
where the second
   // target of that link is an atom bound to the property 'mother'
declared here.
   @To("mother")
   private Woman mother;

   // Link this atom as the first target of a link labeled "father"
where the second
   // target of that link is an atom bound to the property 'father'
declared here.
   @To("father")
   private Man father;

   @From({"mother", "father"})
   private Set<Person> children;

   // Use some predefined link type with a user-specified label
"friend" to connect this
   // person to all their friends. Order of targets in such "Via"
links is not important.
   @Via("friend")
   private Set<Person> friends;
}

public class Company
{
   // The set of employees is taken to be all links pointing to this
atom from target position 1
   @FromTarget(type="Person", position="1")
   private Set<Person> employees;
}

Original comment by borislav...@gmail.com on 8 Jun 2011 at 12:39

[GoogleCodeExporter]

I dive into OrientDB some days:-) which graph operation limit both vertext and 
edge to superclass of library. I have a idea, after focus on those text:
Link/Edge/Relationship must be capable to hang.
Most graph record in and out edge in vertex ends.
try to apply java beans, more commonly, structure, hard.
But if the bridge can hang, some like garden of sky, the applying can be done. 
So the Link/Edge/Relationship can be one end.
In deed, the generalization at last goto oo, all is Object. the LER expand to a 
Vertex level.
Speaking in another way, OO need a graph operation. seems really.

Original comment by saintof...@gmail.com on 20 Jun 2011 at 9:00