Re: [hypergraphdb] Question about Records & HGCompositeTypes

[Alain]

Well welcome to one of my first favorite subject when I first started to use HG.

First, you should make sure that all your classes are JavaBeans and recognized as such by the type system, as this is the minimum to expose your "fields" and avoid you having to manually manage projection and custom types, etc.

Next, you could always just take the Article class that you are showing and save that with HG, it will work. But the problem is that non-primitive "fields" that are contained in your class, will be hidden and opaque and will prevent you from doing the type of query that you are describing with your history.

In order to expose those relations, you have to use links. There is no other way (well there is the HGAtomRef construct that can help a bit in some cases, but it doesn't really solve that problem).

So in summary, only save the primitive in your beans and save each component separately and use links (HGLink) to relate the different objects. Then you can really start enjoying HG with all its power.

Cheers,
Alain

On Tue, Nov 13, 2012 at 8:38 AM, Sandeep Harsha <harsh...@gmail.com> wrote:

Hello,

I keep struggling to grasp the proper way to store particular objects into the database.  Suppose I have an Article.  Without any storage implementations, I might represent it as this:

public class Article {

private String name;

private Contributor creator;

private Set<Piece> components;

private Set<GinRecord> history;

}

So a Piece is a single component of an Article (e.g. Text, Media, Poll), and many of them compose an article.  It is an abstract class, so the Set will actually be populated by Piece's subclasses.

A GinRecord itself has three fields, {GinRibbon type, which is an enum related to the type of modification involved} and {Contributor initiator, pretty self-explanatory} and {String[] details, which gives out information as to the nature of the modification (e.g. previous entry vs. new entry, field changed)}.

Do I have to create an HGProjection type to handle Article.name?

I think I can deal with an HGLink for Article.creator.

Is it better to deal with the relationship between Article and Article.components via another HGLink?  

And for Article.history, how do I make use of the existing Record stuff and still be able to navigate deep within the fields?  I want to be able to execute a HGQuery that involves something akin to a hg.part("history.type", "NAME_CHANGE", ComparisionOperator.EQ) to get a list of all the modifications that have to do with someone changing something's name somewhere.

Thanks.

--
You received this message because you are subscribed to the Google Groups "HyperGraphDB" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hypergraphdb/-/pSyna-fyuf4J.
To post to this group, send email to hyperg...@googlegroups.com.
To unsubscribe from this group, send email to hypergraphdb...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hypergraphdb?hl=en.

[Ingvar Bogdahn]

Hi Sandepp & Alain,

@Alain: with your permission I I'd like to copy & paste your
explanation into the trivial tutorial in an abbreviated form. The
documentation is too scarce on that. I'm still uncertain about that.

Btw, if you have more information to share about this subject, any
experience of how to design data / application for optimal usage with
HGDB, any details would be greatly appreciated and I may equally put
it in the tutorial with your agreement, giving credit.

ingvar

2012/11/13 Alain <alp...@gmail.com>:

[Alain]

You have my full permission, np.

As for how to best use HG in a normal scenario, I'm a bit of a crippled user as we access/use HG with our type system that manages all of the mapping that we are talking about from an Ecore (Eclipse EMF) model. This makes our usage patterns a bit different, even if underneath it's all the same HG.

Alain

[Borislav Iordanov]

Guys,

Thanks so much for helping out with the tutorial! It's always a good
idea for someone else than the author of a software to write a
tutorial on it, it's a always a fresher perspective and one that
newcomers may more easily related to!

Boris

https://plus.google.com/u/0/106165351435577158822/posts

"Damn! The world is big!"

-- Heleni Daly

[Ingvar Bogdahn]

thanks alain. added.
@ Boris you are welcome. glad I can give something back. Do you have
something to add to this?

http://code.google.com/p/hypergraphdb/wiki/TrivialTutorial?ts=1352831299&updated=TrivialTutorial#How_to_design_my_data?

2012/11/13 Borislav Iordanov <borislav...@gmail.com>:

[Borislav Iordanov]

Well, I could add a lot I suppose. I think the main confusion is
probably what role links play in the representation of beans
(specifically nested structures like Sandeep's example). The answer
is: none, links are independent. This means the graph structure is
something orthogonal to (i.e. independent of) the representation of
complex objects. That's a choice I made very early on with the idea
that a value of an atom should be something arbitrary and it shouldn't
interfere with the graph structure.

The idea is that if one wants to represent bean structures at the
level of the atom graph, one can always write custom types to do it.
However the current interfaces don't make it easy to do this in a
generic way. So, as a note about roadmap and the future of HGDB, I
think the type system needs to be redesigned seriously with a change
in the core interfaces (HGAtomType etc.). Alain, and maybe others that
have customized it, will kill me for that, but I think it's necessary
in order to me forward :)

Best,
Boris

On Tue, Nov 13, 2012 at 1:30 PM, Ingvar Bogdahn

[Alain]

On Tue, Nov 13, 2012 at 1:38 PM, Borislav Iordanov <borislav...@gmail.com> wrote:

Well, I could add a lot I suppose. I think the main confusion is
probably what role links play in the representation of beans
(specifically nested structures like Sandeep's example). The answer
is: none, links are independent. This means the graph structure is
something orthogonal  to (i.e. independent of) the representation of
complex objects. That's a choice I made very early on with the idea
that a value of an atom should be something arbitrary and it shouldn't
interfere with the graph structure.

The idea is that if one wants to represent bean structures at the
level of the atom graph, one can always write custom types to do it.
However the current interfaces don't make it easy to do this in a
generic way. So, as a note about roadmap and the future of HGDB, I
think the type system needs to be redesigned seriously with a change
in the core interfaces (HGAtomType etc.). Alain, and maybe others that
have customized it, will kill me for that, but I think it's necessary
in order to me forward :)

Well if we first start by incorporating the changes that we have made and take the changes as having to satisfy both the standard implementation and custom ones like ours, I'm sure I won't go that far :)

Alain

[Sandeep Harsha]

Thank you, Alain.  That greatly refreshes my perspective.

I have another question.  How does the implementation of Record actually work?  Is it just an object that we create an instance of and add to the database, where it reasons with the preexisting RecordType, or do we need to tweak it further?

[Alain]

Sandeep,

The Record and RecordType and part of the type system implementation that you shouldn't have to play with unless you get in the custom types. For what you are showing right now this is overkill. You should let HG manage your beans by itself. It does a very good job at keeping this simple.

I'm including a small example that reveals what you were first asking about querying by type for "nested" bean attributes and some of the challenges around that. You can also see how easy it is to store data in HG.

Cheeers,
Alain

On Tue, Nov 13, 2012 at 3:40 PM, Sandeep Harsha <harsh...@gmail.com> wrote:

Thank you, Alain.  That greatly refreshes my perspective.

I have another question.  How does the implementation of Record actually work?  Is it just an object that we create an instance of and add to the database, where it reasons with the preexisting RecordType, or do we need to tweak it further?

--

You received this message because you are subscribed to the Google Groups "HyperGraphDB" group.

To view this discussion on the web visit https://groups.google.com/d/msg/hypergraphdb/-/SozL6GwBVM4J.