I'm using this tutorial: http://www.objectdb.com/tutorial/jpa/eclipse/ee/ejb
Is the persist function required? The class isn't extending any other classes.
Is DAO required in my model name? I see List<Guest> is <Guest> referring to GuestDao or the package name? If I had to guess I'd say GuestDao
Thanks for clearing this up
The persist method is a type-safe persist method. It can cut down one type of programming error (saving the wrong entity type through the DAO).
It's required in the sense that a GuestDao would be expected to have Guest-specific methods.
It also keeps knowledge of the persistence mechanism itself out of the mainline code: separation of concerns. All the mainline code needs to do is persist guests via the DAO.
Dao is not required in the model name. It would actually be confusing, since it wouldn't be a DAO. Guest refers to a guest. GuestDao refers to a DAO for Guests.
List<Guest> refers to a collection of guests. List is a generic type, the symbol between the "<>" is the collection type, in this case, Guest. Guest refers to exactly that--the Guest class.
Inside of List<?> is the type.
There should be another domain class called Guest. Is it mentioned in the tutorial or earlier? Guest class should contain all the attributes of the Guest domain class, i.e. name, telephoneNo etc.
Related
I have an #Embeddable class with two fields: type and value. Both fields map to the corresponding database columns. The first one is enum and the latter one is an interface that has multiple implementations.
Only certain combinations of type and value are considered valid even if type and value are correct in isolation. How can I perform such validation, when I retrieve the entity that owns the #Embeddable from the database?
I could perform validation inside no-args-constructor of embeddable, but as far as I'm concerned, Hibernate creates new #Embeddable instance with no-args-constructor and then injects the values with Java Reflection API. Therefore, if I access these two fields inside the constructor they will be null.
Is there an approach to register some PostLoad hook for the #Embeddable classes that Hibernate will trigger? I though about declaring PostLoad inside the entity itself and then calling MyEmbeddable.validate directly. But I think it's a dirty approach.
I added the class-level annotation to validate the whole object. It did work. Check out this question for more details.
So, I have an object-oriented assignment to do. Small part of it is to make a graph, made out of nodes, which can be either a type category or type product.
The category has only a name ([a-zA-Z0-9]+) as parameters.
The product hast a name ([a-zA-Z0-9]+) and an id (>=0).
At the beginning a made just a node, with two objects category in product, which where both null, and depending on the input I created an instance of one of the two things, and everything was fine.
I really put a thought in it and after I checked the lectures I found about the thing abstract classes :D . No my idea is to make Node abstract and Product and Category extending Node,since:
Category has setter and getter for Name and toString
Product has setter and getter for Name AND ID (of course) and toString.
Setter,getter and toString for Name are identical.
There's a differnce in the constructor for Product, because it sets also the ID.
So,
Is it going to work that way, is it better?
Can I create a Node and then after the input say -> this node is from type category
You cannot just create a Node if it is abstract.
You should be getting the input, and in that probably the type that wants to be created, and create the appropriate non abstract class for that one.
Alternatively you can create them as Category and if the user types an Id create a new Product and copy the data across from the first object to the second. But that doesn't makes much sense.
Seems like category should just be part of product. That is you have a category class, and a product class which has two properties: category class and id. That way, you can create a category out of any point on your graph, and then if it is a product, pass it to a second constructor to give it an id.
I think this should be an abstract method validate that each node type can implement independently.
Node suggests that this is a graph of states that you're navigating. Perhaps you want a method to fire on entering or leaving that state. Each type can put whatever they need into it. Interfaces and strategy patterns will help here.
Keep the graph separate from what's done.
I have three classes that are subclasses of the abstract superclass Automobile. I'm using the single table inheritance model and a #MappedSuperclass for the automobile class. The subclasses are Car, Truck, and Van.
I want to query the automobile class, but have the different subclasses returned. I've written a couple queries and done some research, but it seems like it is not possible to query against MappedSuperclasses. I have also tried to do NativeSqlQueries, but I can't seem to be able to figure out how to specifiy multiple ResultSetMappings.
Is there anyway to accomplish this?
You cannot use a mapped-superclass in the query. If you want to use Automobile in the query, don't mark it as mapped-superclass, instead mark it as an entity.
Following is from the JPA 2.0 Spec, second paragraph is what's relevant in your case -
2.11.2 Mapped Superclasses
An entity may inherit from a superclass that provides persistent entity state and mapping information, but which is not itself an entity. Typically, the purpose of such a mapped superclass is to define state and mapping information that is common to multiple entity classes.
A mapped superclass, unlike an entity, is not queryable and must not be passed as an argument to EntityManager or Query operations. Persistent relationships defined by a mapped superclass must
be unidirectional.
I have a question that may seem pretty trivial to many, but it's one that has made me think repeatedly about the readability of the code that I write.
Lets assume that I have a class that encapsulates details of an entity, such as an employee, called EmployeeDetails. (Note - I also have a class named Employee which exists at the DAO layer. I do not want to return any DAO level classes from my service methods, which is why I created the EmployeeDetails class to be returned from my service layer methods. I also wanted to avoid confusion between class names by keeping the service and DAO layer class names distinct).
I also have a service level method that, given a list of Employee numbers, returns a List<EmployeeDetails>. My question is this - what is the best coding convention for naming the return variable? I had two options in mind.
employeeDtls - I do not like this because the person who reads my code may think that "employeeDtls" refers to an instance of EmployeeDetails instead of a list.
employeeDtlsList - I do not like this because it seems "too wordy".
Does anyone follow any specific coding conventions for variables? What is the most widely used naming convention for list variables?
Well...let's consider what we're modeling here.
A general rule of thumb, is that if it's a collection, then it should be pluralized and scoped to the contents of what you expect.
So, that'd make your variable name List<EmployeeDetails> details or List<EmployeeDetails> employees. If you can help it, try to avoid the compound name, unless that truly and concretely represents what it is you're getting back.
If you were using the Data Transfer Object model, and you had named it something along the lines of EmployeeDto, then the name of the variable would be more specific at employees, as you expect back some collection of something representing an Employee (at its core).
I usually name the return variable result, for all methods:
List<EmployeeDetails> result;
The reason is that it's obvious which list I'm adding to, and that it's gong to be returned, especially if there are multiple lists within the method.
This also conforms to good practice by naming things for what they represent, rather than what are they are. Your idea is a bit like naming an int variable as intVariable. Naming it simply result means you can change they type of the result, eg to Set<EmployeeDetails> without any refactoring of the name.
I would rather call the class EmployeeDetail so it is a singular noun which represent "detail information" of an employee.
Then the variable naming will be straight forward for its collection : employeeDetails
In case I really encounter a class named in plural form (for which I usually try to avoid), I usually use ~List as the variable name for the collection of such type. Although it is a bit too verbose, at least it doesn't cause any confusion.
Use DTO (Data Transfer Object) pattern to carry the data of underlying entity.
In your case, EmployeeDetails should be EmployeeDTO
Take a look at discussion here
All,
I have to be doing this wrong. It seemed like a good idea at the time but as I get deeper into it, I think there is a more proper programmatic way of going about it. Thus I ask you...
One note. I'm using Google AppEngine and the Datastore to store this information.
Ok... lets say I have a Super Class of Vehicle, which then has 3 Sub-Classes... Car, Truck, Motorcycle.
In the Super Class, there are 3 properties... Manufacturer, Model, Type
For example, these might be:
Manufacturer: Ford
Model: Focus
Type: Car
So in the Datastore, I have numerous Vehicle entities with these properties.
So if the user wants to see all the cars... I pull everyhing with a "Car" type.
If the user then wants to add one of these Vehicles to a "favorites" list, I then convert the Vehicle object into its specific Sub-Class based upon what type it is. This then adds the extra properties of that specific Sub-Class.
This new child entity is store in the Datastore with its added properties.
So basically, I'm downcasting, for example, from a Vehicle to a Car. I have done this by creating an extra constuctor in the Car class that takes Vehicle as an argument. Once created, the Car object now has all the properties (Manufacturer, Model, Type) set, and all the new properties that come with its specific implementation.
This just seems convoluted and wrong. It works but there has got to be a better way of doing this.
The main reason I chose this way is because of the way the GAE Datastore works. Its "cheaper" to store the Super Class and its limited properties and query those. Long story.
I'm trying to wrap my head around using Interfaces and/or Abstract classes for this but I wanted to get all of your input.
Thanks for the help.
I don't think you want a super/sub class structure here. Your problem as described has you "changing" an object from one type to another, and you cannot change the type of a Java object. You can create a new object, but then you have to move all your information from one to another, and maintenance becomes a problem.
I suggest that you have a class that represents your vehicle, and that it contain a reference to type-specific information; the classes representing each specific type can all extend something, and probably should so that methods within vehicle trying to do something with the type can call a common method to do it regardless of type. But this way, once you decide the specific type, you can add it to an existing vehicle object instead of "changing" it.
You could also explore whether an enumerated type would serve your purpose for type-specific data -- enum types can take constructors, have additional methods, etc. - the Oracle/Java tutorial on enums covers that pretty well.
The type of vehicle is encoded twice: once as an object type, and once as a property. Get rid of one of these, so that there is not a possibility of having a Truck (object type) with property value set to Car. Keep your object structure, or property pointing out the kind of vehicle (I recommend using an Enum), but not both.
To downcast, you do not need to create a new object of the child type. Just downcast:
Car myCar = (vehicle instanceof Car ? (Car)vehicle : null);