I am reading a book about EJB, I see the term "a leaf entity" but I am not sure what it means. As far as I can guess from the context, it is a concrete entity that can be instatiated. However, later I found in the book that the non-leaf entity can also be concrete. Could anyone tell me the difference between the two?
Many thanks!
Whether an entity is concrete or abstract is only an indirect result of whether it is a leaf or otherwise. The differentiation is in the inheritance.
A leaf entity has no subclasses, therefore must be instantiable.
An intermediate entity has subclasses (and inherits from a class closer to the root entity) and may (or may not) be instantiable.
From Beginning EJB 3 Application Development: <- Link to pdf download
An abstract entity must be an intermediate class in an entity inheritance hierarchy - it may not itself be a leaf entity since it may only be instantiated through one of its subentities. Correspondingly, all leaf entities in an entity inheritance hierarchy must be concrete, and therefore instantiable.
Related
I was going over some of the docs here.
I was curious why Grakn opts to indicate relations using noun semantics rather than verb semantics? In most of the other graph work and research I’ve covered, it usually makes sense to think that two entities (nouns) are linked by a verb e.g. person worked at company. Indeed, for a few entities that I am dealing with, it is a bit difficult to reason about the relationships as nouns for example if artist remixed track.
I’m inclined to use verbs as relations but I wonder if that is not how I should be thinking about it in a Grakn setup. Are there eventual difficulties I can expect to face if I decide to use verb semantics?
Typically, graph databases use directed edges to represent binary relations. Under those circumstances it makes sense to use a verb to describe a relation, since verbs often indicate a directional action between a subject and an object.
Grakn is a knowledge graph, which works differently. This is because relations in Grakn act as hyperedges. This means that there can be more than two participants (called roleplayers) in a relation. This is great for flexible modelling, but it can break the verb naming convention.
To work from your example, rather than artist remixed track, we could (very conveniently in this case) use the noun remix as the relation. Taking a guess at the domain model, an artist remixes a track, and as a result they have created a new track. That’s a great opportunity for a ternary (3-way) relation in grakn. The model for that would be as follows:
define
remix sub relation,
relates original-track,
relates remixed-track,
relates remixing-artist;
track sub entity,
plays original-track,
plays remixed-track;
artist sub entity,
plays remixing-artist;
Once the schema above has been defined in Grakn, we can add a remix instance connecting two new tracks and a new artist like so:
insert
$o isa track, has name "Brimful of Asha";
$rt isa track, has name "Brimful of Asha (Norman Cook Remix)";
$a isa artist, has name "Norman Cook";
$r(original-track: $o, remixed-track: $rt, remixing-artist: $a) isa remix;
It has then proved useful to use a noun for the relation because it doesn’t connect any of the 3 roleplayers it can have in a binary way. Instead we have named the concept that sits in-between the two tracks and the artist.
In this way we see that the relation nicely describes the (undirected) link between any pair of the roles:
original-track <-remix-> remixed-track
original-track <-remix-> remixing-artist
remixed-track <-remix-> remixing-artist
We can see that using remixed in place of remix wouldn't work so well, it would try to add direction to these links where there is none.
Grakn's data model can be extended on-the-fly. Therefore even if you start with a binary relation, should you later add more roles, making it ternary or N-ary, verb naming will no longer make sense.
It’s not always easy to name relations with nouns.
My suggestions are:
first try using a past or present participle of a verb (used as an adjective) with a noun. For example the role remixing-artist uses this.
resort to verbs when using nouns is really awkward, and/or if you’re dealing with a relation that you expect always to be binary.
If you must use verbs as relation names, then use the gerund form (which for all practical effects, acts like a noun). e.g.
faceting sub relation,
relates facet-assignment,
relates assigned-facet.
listing sub relation,
relates list-assignment,
relates assigned-list.
I'm coding an application to create surveys with Symfony3 and Doctrine. I would like to understand which is the best way to model the relation between the survey, items, and answers. A survey is composed by multiple items that have peculiar typologies of answer. For instance I could have the following typologies:
AnswerChoice
AnswerText
AnswerRange
etc..
Which is the best way to model this scenario with Doctrine?
I thought 2 possible solutions:
I create a single Answer object including every possible feature of the answers. The Item object should have a one-to-one relationship with this objects.
Pros: I have just one answer object
Cons: Confusing and against the single responsibility principle
I create a generic Item object containing a specific Answer object (AnswerChoice, AnswerText...) in a predefined class property. The Survey object should have a one-to-many relationship with Item that in turn will have a one-to-one relationship with a specific Answer object;
Pros: Nice solution but...
Cons: I need a property for each type of answer!
Could you please help me to choice the best solution? I have the feeling that I'm not facing well this problem. Thanks
It's inheritance. Actually Doctrine handles inheritance pretty well.
There are a few ways of implementing inheritance in Doctrine but I think, that in your case Single Table Inheritance is what you're looking for.
That way you will be able to get a repository for parent (abstract) answer,but you'll get instances of actual child types in return.
is there a way to get the recursive superclass concepts of a concept from freebase? For example, i would call the topic "/games/game_publisher" a concept, and I would like to know if it has any superclasses (e.g., /organization/organization would make sense).
Many thanks!
Freebase Types (the equivalent of your "concept") don't have an inheritance structure. They do however have "included types". One key difference is that an included type only gets added to a topic by when it's main type does by convention of the web client (or other client), but after that it can be removed or re-added independently. For example, Deceased Person has Person as an included type and it's unlikely anyone would ever remove the latter, but Author also has Person as included type because that's the case for the overwhelming majority of authors, but for so-called "corporate authors" one would remove Person and add Organization.
So, the included types does carry some semantic information, but it's not as strong as a super/sub-class relationship.
I am trying to define when to name a class as a Context and I am having a very difficult time. Could someone please define "Context" for me and explain when to name a class "Context"?
Dictionary.com (Random House Dictionary, © Random House, Inc. 2011) defines context as:
the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect: You have misinterpreted my remark because you took it out of context.
the set of circumstances or facts that surround a particular event, situation, etc.
The second definition is the applicable definition in this case. Taking the HTTPContext class for example, we know that the class contains information about the web site at the current moment (including the request, the response, the session, the user, etc.)
Therefore, I would define a 'Context' in this regard as a class that provides information about a particular application or service; or provides access to objects and methods that describe the current state of an application (or a particular facet of an application, such as a DataContext class in Linq To SQL or Entity Framework).
If you look up the Oxford English Dictionary for "context" it tells us:
the circumstances that form the
setting for an event, statement, or
idea, and in terms of which it can be
fully understood:
In programming a "context" class would be a class that provides your application code or code running within a framework with a set of data or objects relevant and meaningful to the task at hand.
For example, ASP.NET's HttpContext object provides information about the current HttpRequest (cookies, headers, user agent and so on). This data is meaningful only in the "context" of the current request as it may and will change for other requests.
I'm looking for opinions on best practices with regards to passing entities beyond assembly boundaries. I'm using Linq-To-SQL, but the same question would apply to Entity Framework, NHibernate, etc.
I have an assembly that I want to reuse in multiple projects. In it there are several entities which I have so far kept internal, however I am finding it would be beneficial to return a list of the entities to the caller. Should I create a new class to encapsulate the data or should I just expose the entity itself.
For example, let's say I have an Address entity. Would it be better to have a method GetAddress(...) that returns the Address entity, or should I create another class with the same properties to expose the Address data?
Thanks!
One vote for just exposing the entities. In practice, the reasons for hiding the entities behind DTOs end up not really being relevant. For example, when was the last time you ripped out your internal data access layer for something entirely different that would have caused you to lose the auto-generated entity classes?
Plus you get to save time by avoiding the painful mapping exercise that ensues when you only expose DTOs. IMO, having an automatic mapping tool that uses reflection or something doesn't count as no pain because now you pay in performance what you would otherwise pay in tedium.
You might want to consider using a Repository to expose the Entities to outside assemblies. Here is a great CodeProject article on a generic Repository that can be used with EF.