I have a bunch of questions regarding Java 8 and SDN4. I created a model in Neo4j v3.0, played a bit with Cypher queries, and now moved to creating a Spring Boot application. As i started coding classes in Java, I've begun to rethink some of my model as well. Here's some questions in my mind (and I haven't found an example explaining this):
Do you need to use Interfaces in Java, with SDN?For eg. I'd code a Product interface and then have my products implement it, but is that how it's done when working with labels?
This is somewhat tied to my question on inheritance - I'd usually have a ProductFamily that my Product would inherit from. At the database level its modeled as (:Product)-[PartOf]->(:ProductFamily), but in the code these would not be super/sub class.
Any examples of using Generics in a graph context?
Is there a way to define constraints on what relationships a node can have and their direction in Java?
I understand there is probably not one right answer, but there's precious little on the web, so hope to get enlightened here!
If you had a Product interface annotated with #NodeEntity, then the you'll have the Product label in addition to the label on your implementing class, which I assume is what you want. If your interface isn't annotated, then your implementing classes will not inherit a label from it.
Not sure what you mean- if you say you have a ProductFamily that Product inherits from, but in the code it would not be a super/sub class?
Based on your graph model, if you want (:Product)-[PartOf]->(:ProductFamily) then you will have a Product class that maintains a reference to a ProductFamily class, and that reference annotated with #Relationship. If the Product class inherits from ProductFamily then persisting the Product will result in two labels- Product and ProductFamily because a Product IS-A ProductFamily.
How do you see yourself using generics- the answer really depends on that. Some cases are supported, some are not (an example of something not supported right now is equivalent of template.createRelationBetween in SDN4)
Yes, via the #Relationship annotation which accepts a type and direction. Note that this annotation only constrains your domain model, but you could very well flout this by creating relationships in another direction via a custom query.
Related
Let's say we want to make an ontology model for the Light Switches in the home.Each Light Switch has two properties hasID, and hasLocation.
which way is the most correct way to doing it.
making a class LightSwitch
a data property hasID
an object property hasLocation
some individual Like LightSwitch-01, LightSwitch-02
OR
making a class LightSwitch
subclasses KitchenLightSwitch, LivingroomLightSwitch, and etc.
a data property hasID
an object property hasLocation
some individual Like LightSwitch-01, LightSwitch-02
In ontology design there is no right or wrong in general (of course there are situations where someone makes mistakes in the design process).
There is no such thing like "this is the one and only solution". There are always different solutions, based on your scenario, experience and what you would like to do with the ontology.
In your case you could solve your problem with both approaches (I would prefer the second one, since I'm a fan of classes). The only difference in your example that I see is that in the first one all lightswitch instances are of the type "LightSwitch" and in the second one the instances are of theire location type (e.g. KitchenLightSwitch).
However if you are using the object property "hasLocation" you do not really need subclasses for "LightSwitch".
Create a class "Lightswitch" with the instances "Switch1, Switch2,..." and create a class Room with instances (Kitchen, Livingroom, etc).
In the last step you associate a relationship: Switch1 hasLocation Kitchen.
Another possibility would be to create the class Room and subclasses LivingRoom, KitchenRoom, etc. Each of the subclasses would have an instance "kitchenroom, livingroom, etc."
But really, its up to you. I see nothing wrong with both of your solutions. However, if you would provide more information or your context would be more complex.. maybe then one could prefer either solution A or solution B, but for exactly this example that you are asking for, both solutions are right.
So I want to create 3 plugins which include domain classes and a restful service, and who each build on top of each other.
Conceptually, they would "inherit" the base model this way:
Record > Person > User
However I have Read From The Friendly Manual that inheritance may cause some performance issues.
Then it crossed my mind that since Groovy has horizontal reuse capabilities (i.e. traits), I may very well just define everything in the trait and then implement the trait in the domain class.
Composing domain classes is not an option for me because of the renaming of the fields, and well, the loss of the convenience of IDE auto-completion.
My two questions are:
In what part of the Grails project structure would it be best to place these traits.
Can this cause different problems?
The Trait source code should be in
Grails 2: src/groovy/[package][whatever.groovy]
Grails 3: src/main/groovy/[package][whatever.groovy]
For example: src/main/groovy/com/my/package/foo.groovy
The main issue you'll have is that you'll loose the ability to perform polymorphic queries. For example, with inheritance you can do something like this:
def everything = Record.list()
and everything would contain Record, Person, and User instances. Kind of like a SQL union query. When using Traits instead of inheritance you loose this ability.
I'm trying to implement the OpenEHR reference model in Rails (ActiveRecord), but I'm finding some problems, since it works with a lot of different of different classess,
Here is the diagram of a Composition:
As you can see, a lot of classes "inherit" a couple of attributes from Locatable or Pathable* (the whole reference is huge, and almost every class inherit from it).
Also, it establish data_types as other classes, for example in the same composition class, language is class CODE_PHRASE, that have two attributes (link).
Therefore I encounter two problems 1) how can I inherit attributes from abstract classes, and 2) how is that I can "include" the needed "classes".
For the first problem I thought in using Polymorphic Associations.
For the second one, I thought using STI, but I'm quickly finding a lot of almost similar models (they are exactly the same actually): CompositionLanguage, CompositionTerritory, EntrySetting, EntryEncoding that I only use in the type attribute to "link back", for example: The composition class, can have up to three attributes with CODE_PHRASE, since all three references a different attribute (language, territory and category), I thought that I needed to know for the associations (there's no point in knowing that Composition has 3 code_phrases, but I didn't know which one is the corresponding attribute). On the other hand, the Entry class, have the setting and encoding attribute (link).
I realize that there could be different approaches, but I would really like to know if that maybe Rails (or ActiveRecord), wasn't made for this. Or, maybe I'm missing conceptual info.
The openEHR RM specification has deeply nested inheritance and composite patterns with tree hierarchy.
I could not implement this nested inheritance by ActiveRecord. The following implementation is an example to simulate openEHR RM.
I would be very happy if this example could help you.
https://github.com/skoba/openehr_rm_rails
Have you looked at this project ..
https://github.com/skoba/openehr-rails
I think Shinji uses Active Record.
Personally, given the complex structure of the openEHR RM, if I was starting out I might look to use something like MongoDB with an ORM.
I have pointed the openehr technical community to your question via the openehr technical list to see if others can help.
Ian
Is there a way to add more belongs-to relationships to an imported GORM domain class? Specifically, I'm attempting to use table-per-class to extend a shared subclass, but if I do this in two (or more) locations, and the locations do not have knowledge of each-other then things like:
set.addToParents(parentSet)
Start leading to:
org.hibernate.WrongClassException: Object [id=3482] was not of the specified subclass [com.acumenllc.domaincore.DbSet] : Discriminator: com.acumenllc.tickets.domain.TicketSet
happening everywhere.
A little more background, I'm working on a closure table to keep track of related objects. The base class recognizes the parent-child bi-directional relationship, as well as the ancestor-descendant extension of it. Different applications then extend this class with belongsTo relationships on objects to be represented as nodes in the resultant graph. We specifically want to be able to more-or-less ignore some of these other classes in other applications that happen to share the same database.
Ideally, it would be possible to import our base domain class into a new application and, rather than extending into a subclass, re-define the set of relationships that the base class recognizes in the scope of the application.
The only practical way I can see of doing this is with .hbm.xml files. The GORM approach of including hasMany/belongsTo in the code and JPA's approach using annotations are both fairly inflexible to support this sort of mapping. But if you separate the configuration from the code, you can define the relationships for different applications however you like. Creating a hibernate.cfg.xml file and the hbm.xml files is described here in the docs.
This is possibly a bit of a stupid question, but I am getting confused due to the ASP.NET MVC book I am currently reading...
Working with Linq-To-SQL it seems to say that it is not good practice to pass the Linq-to-SQL objects straight to the controller, but that each object should be modelled separately first and this should be passed between the controller and the repository.
Say, I have a database of products. Linq-to-SQl creates a product class for me with Name, Price and Whatnotelse properties. I could pass that straight from repository to controller and then view, but instead it seems to recommend that I use and third class, say Product_Entity, with also Name, Price etc. properties and pass that to the controller.
I fail to see the benefit of this approach, except possibly for adding attributes to the properties... But apart from that it seems to have more drawbacks than benefits. Say each product has manufacturer information as well, I don't see how I can model that easily in my third class.
Is this approach really best practice? Or did I misunderstand all that? If so, why is it bad to work straight off the linq-to-sql generated objects? And how do you deal with relationships between objects in y
The huge benefit to this other class you create is that, to use your example, it doesn't necessarily map to either a product or a manufacturer. Think about it like this:
Your Linq to SQL classes are meant for talking in the "data" domain.
Your "data" classes (the ones you're having trouble with) are meant for talking in the "application" domain.
Let's take an example. Suppose in your MVC application you wanted to show a grid of information about products. You want to see their Name, Price (from the Product table) and their Country of Manufacture and Manufacturer name (from the Manufacturer table). What would you name this class? Product_Manufacturer? What if later on you wanted to add properties from yet a third table such as product discounts? Instead of thinking about these objects in purely the data domain, think about them with regard to your application.
So instead of Product_Manufacturer, what about calling it ProductSummaryItem? Each property of the ProductSummaryItem class would map 1:1 with a field shown in your grid on the UI. Your controller would perform the mapping between the information in the data domain (Product, Manufacturer) with the custom class you'd created in the application domain (ProductSummaryItem).
By doing this, you get some awesome benefits:
1) Writing your views becomes really, really simple. All you have to do to display your data is loop through the ProductSummaryItems and wrap them in and tags, and you're done. It also allows for simple aggregation. Say for example you wanted to add a field called ProductsSoldLastYear to your ProductSummaryItem class. You could do that very simply in your views because all it is to them is another property.
2) Since the view is trivial and there's mapping logic in the controller, it becomes much easier to test the controller's output because it's customized to what the view is going to see.
3) Since the ProductSummaryItem class only has the data it needs, your queries can potentially become much faster because they only need to query for the fields that would populate your ProductSummaryItem object, and nothing else. This overhead can become overbearing the more data-domain objects make up your ProductSummaryItem object.
This pattern is called Model View ViewModel (MVVM) and is hugely popular with MVC as well as in frameworks like WPF.
The argument against MVVM is that you have to somewhat reimplement simple classes for CRUD operations. Fair enough, I guess, but you can use a tool like automapper to help out with things like that. I think you'll find fairly quickly, though, that using the MVVM pattern even for CRUD pays dividends, because before you know it, even with simple classes, you'll start wishing you had extra fields which can easily drive your views.