I have a class structure which is akin to a PurchaseOrder (parent) and PurchaseOrderLine (child) pattern, where the order lines will only be saved to the DB by saving the parent PurchaseOrder and will only ever be accessed via the parent too.
The DB has PurchaseOrderLine.PurchaseOrder set to not permit null values.
It seems from searching through the web that it is not possible to have a uni-directional association from PurchaseOrder via an IList property without having to have a property on the line pointing back when the child has a NOT NULL constraint for its PurchaseOrder column.
Is this really the case? It seems like one of the most basic things one would want to do with an ORM, I find it difficult to accept that a product as mature as NHibernate cannot handle such a basic scenario.
No it's not the case. Please see the example provided in the answer to this question: When to use inverse=false on NHibernate / Hibernate OneToMany relationships?
Well, it may be the case that you can't have unidirectional one-to-many relationship defined only on one side, but I'll argue with your statement that this is "one of the most basic things one would want to do with an ORM".
One of the most basic things would be to have unidirectional one-to-many defined only on many side - as it is natural for RDBM tables. And ORMs (despite the common misconception) are not intended (or able) to fully abstract domain model from underlying data source. Even if in some cases they can, the database side suffers from select N+1 problems or very ineffective queries.
Defining one-to-many at one side makes an impression that i.e. counting the collection is cheap. It is the case with plain object graphs, but not with NHibernate entities, as reading collection causes (at least one) call to the database. Eager fetching from one side is also not able to properly use database join mechanism in the way it's intended to be used (opposite to eager fetch from many side).
Even if I don't agree with a lot of arguments, I think it is useful to read some of the articles saying that "ORM is an anti-pattern", like this one. They helped me to leverage the way I think about ORMs and make me think about ORMs as a compromise between two not matching paradigms, but not the way to hide one behind another.
This can now be achieved in NH3 using the Not.KeyNullable()
this.HasMany(x => x.Actions)
.Access.BackingField()
.KeyColumn("[Application]")
.Not.KeyNullable()
.Cascade.AllDeleteOrphan();
Related
I have those four tables in database :
USER
id
PERMISSION
id
OBJECT
id
CONTEXT
id
Now the problem is that I want to link them to say that a user has one or many permissions on one or many objects depending of a context.. It looks simple but I can't find a way to avoid n-ary association..
Hope someone will be kind enough helping me to solve this problem.
Thanks in advance.
You may be looking for something like a WEAK ENTITY
Basically, a weak entity is a database entity which doesn't make sense on its own, but needs one (or more) foreign keys to assume a proper identity and a meaning.
This means that you're moving from an N-ary relationship to N binary relationships.
One possible approach is this: let's say that we call this weak entity Rules
Rules(id, user_id, permission_id, object_id, context_id /*other columns*/);
each of your strong entities has a relationship with the rules table. I don't like a lot this approach, but for small datasets it may work pretty well.
As a general note, though, I suggest you to think a bit more about your database model: are you absolutely, positively sure that all these 4 entities have a so strong relationship together? For example, does "Context" has influence on users, objects and permissions or just on permissions? Does an object exists at the same time across multiple contexts, or it makes sense to bind an object inside a specific context (the same concept of a variable scope)?
Doctrine2 ORM have 2 technical ways to handle many-to-many associations :
1/ For a "simple" relation between 2 entities, and without additionnal attribute :
Use #ManyToMany associations between entities
In this case, the link table is used directly, without an association entity
2/ When link table introduces extra fields or more than 2 entities :
Use an association class, ie an "real" entity to map the link table
In this case, the direct ManyToMany association is replaced by OneToMany/ManyToOne associations between the participating entities
These 2 implementations are quite different.
But, in some cases, future business requirements can quickly need to change simple associations, by adding extra fields for example.
In this case, we must replace direct ManyToMany associations in existing entities by the second implementation and refactor affected code.
So, is it a good way to always use association entities to handle all
ManyToMany associations ?
Otherwise, what are the best practices for
choosing the good implementation and handle these kind of domain
model evolutions ?
If you have a good reason to belief that in the near future you will have extra properties on your ManyToMany join table then it's a good idea to make an entity out of precaution. If not then it's better to use the normal ManyToMany relationship. Then when a change is needed you can update your schema along with your code. If you try to follow the Single responsibility principle then you can avoid refactoring large amounts of code.
Say you need to architect an app with an entity that can be associated with multiple other kinds of entities. For example, you have a Picture entity that can be associated with a Meal entity, a Person entity, a Boardroom entity, a Furniture entity, etc. I can think of a number of different ways to address this problem, but -- perhaps because I'm new to Core Data -- I'm not comfortable with any of them.
The most obvious approach that comes to mind is simply creating a relationship between Picture and each entity that supports associated pictures, but this seems sloppy since pictures will have multiple "null pointers."
Another possibility is creating a superentity -- Pictureable -- or something. Every entity that supports associated pictures would be a subentity of Pictureable, and Picture itself would have a one-to-one with Pictureable. I find this approach troubling because it can't be used more than once in the context of a project (since Core Data doesn't support multiple inheritance) AND the way Core Data seems to create one table for any given root entity -- assuming a SQLite backing -- has me afeard of grouping a whole bunch of disparate subentities under the umbrella of a common superentity (I realize that thinking along these lines may smack of premature optimization, so let me know if I'm being a ninny).
A third approach is to create a composite key for Picture that consists of a "type" and a "UID." Assuming every entity in my data model has a UID, I can use this key to derive an associated managed object from a Picture instance and vice versa. This approach worries me because it sounds like it might get slow when fetching en masse; it also doesn't feel native enough to me.
A fourth approach -- the one I'm leaning towards for the app I'm working on -- is creating subentities for both Picture and X (where X is either Meal, Person, Boardroom, etc.) and creating a one-to-one between both of those subentities. While this approach seems like the lesser of all evils, it still seems abstruse to my untrained eye, so I wonder if there's a better way.
Edit 1: In the last paragraph, I meant to say I'm leaning towards creating subentities just for Picture, not both Picture and X.
I think the best variations on this theme are (not necessarily in order):
Use separate entities for the pictures associated with Meal, Person, Boardroom, etc. Those entities might all have the same attributes, and they might in fact all be implemented using the same class. There's nothing wrong with that, and it makes it simple to have a bidirectional relationship between each kind of entity and the entity that stores its picture.
Make the picture an attribute of each of the entity types rather than a separate entity. This isn't a great plan with respect to efficiency if you're storing the actual picture data in the database, but it'd be fine if you store the image as a separate file and store the path to that file in an attribute. If the images or the number of records is small, it may not really be a problem even if you do store the image data in the database.
Use a single entity for all the pictures but omit the inverse relationship back to the associated entity. There's a helpful SO question that considers this, and the accepted answer links to the even more helpful Unidirectional Relationships section of the docs. This can be a nice solution to your problem if you don't need the picture->owner relationship, but you should understand the possible risk before you go down that road.
Give your picture entity separate relationships for each possible kind of owner, as you described in the first option you listed. If you'll need to be able to access all the pictures as a group and you need a relationship from the picture back to its owner, and if the number of possible owner entities is relatively small, this might be your best option even if it seems sloppy to have empty attributes.
As you noticed, when you use inheritance with your entities, all the sub-entities end up together in one big table. So, your fourth option (using sub-entities for each kind of picture) is similar under the hood to your first option.
Thinking more about this question, I'm inclined toward using entity inheritance to create subentities for the pictures associated with each type of owner entity. The Picture entity would store just the data that's associated with any picture. Each subentity, like MealPicture and PersonPicture, would add a relationship to it's own particular sort of owner. This way, you get bidirectional Meal<->MealPicture and Person<->PersonPicture relationships, and because each subentity inherits all the common Picture stuff you avoid the DRY violation that was bugging you. In short, you get most of the best parts of options 1 and 3 above. Under the hood, Core Data manages the pictures as in option 4 above, but in use each of the picture subentities only exposes a single relationship.
Just to expand a bit on Caleb's excellent summation...
I think it's important not to over emphasize the similarities between entities and classes. Both are abstractions that help define concrete objects but entities are very "lightweight" compared to classes. For one thing, entities don't have behaviors but just properties. For another, they exist purely to provide other concrete objects e.g. managed object context and persistent stores, a description of the data model so those concrete objects can piece everything together.
In fact, under the hood, there is no NSEntity class, there is only an NSEnitity***Description*** class. Entities are really just descriptions of how the objects in an object graph will fit together. As such, you really don't get all the overhead an inefficiency of multiplying classes when you multiply entities e.g. having a bunch of largely duplicate entities doesn't slow down the app, use more memory, interfere with method chains etc.
So, don't be afraid to use multiple seemingly redundant entities when that is the simplest solution. In Core Data, that is often the most elegant solution.
I am struggling with esactly this dilemma right now. I have many different entities in my model that can be "quantified". Say I have Apple, Pear, Farmer for all of those Entities, I need a AppleStack, PearStack, FarmerGroup, which are all just object+number. I need a generic approach to this because I want to support it in a model editor I am writing, so I decided I will define a ObjectValue abstract entity with attributes object, value. Then I will create child entities of ObjectValue and will subclass them and declare a valueEntity constant. this way I define it only once and I can write generic code that, for example, returns the possible values of the object relationship. Moreover if I need special attributes (and I actually do for a few of those) I can still add them in the child entities.
I thought it was about time to have a look at OO databases and decided to use db4o for my next little project - a small library.
Consider the following objects: Book, Category.
A Book can be in 0-n categories and a Category can be applied to 0-m Books.
My first thought is to have a joining object such as BookCatecory but after a bit of Googling I see that this is not appropriate for 'Real OO'.
So another approach (recommended by many) is to have a list in both objects: Book.categories and Category.books. One side handles the relationship: Book.addCategory adds Category to Book.categories and Book to Category.books. How to handle commits and rollbacks when 2 objects are been altered within one method call?
What are your thoughts? The second approach has obvious advantages but, for me at least, the first 'feels' right (better normed).
There are really only two ways I can think of to solve this problem, both of which you've mentioned. Personally, I would go with the first approach (creating a mapping object as an OO entity). This prevents you from keeping redundant information around and having to synchronize; it also means that if the association ends up having fields of its own (the date that the book was assigned to that category, let's say), they can be incorporated easily. We use this approach for a variety of associations in our system.
The OO entities would look like:
BookCategory {
Book book
Category category
}
Book {
Collection <BookCategory> categories
}
Category {
Collection <BookCategory> categories
}
Here you have to keep the relation object and the two collections in synch; however, the collections are optional in this case. Typically you could get the same information with an ORM query, something like:
select b.book from BookCategory b where b.category = MyCategory
The alternative is to have a setup like:
Book {
Collection<Category> categories
}
Category {
Collection<Books> books
}
If your ORM/DB tool automatically maintains the associations, this is fine; otherwise, you are stuck updating both collections. (In Hibernate, one side will have the property: inverse=true on the mapping; this side is not updated, so strictly speaking it doesn't need to be maintained. This seems to me like bad practice, though.)
If you typically only access the relation one way (for example, getting all of the books in a category), you could eliminate the collection on other side; then I think you would have to work around the ORM tool and use a native query in order to access the relationship from the other direction.
We use Hibernate (a java-based Object Relational Mapping tool) on our project; the Hibernate docs are a good reference for OO/relational design problems, though you may have to spend a little time learning Hibernate to make them useful:
http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues
HTH!
If you use object database you don't need to care how relations are stored in database. You define classes and relationships between them. Please read the reference guided to your database. Examples of relationships:
n:n attribute, referencing from the parent
------------------------------------------------------------------
class Person {
List addresses;
}
class Address {
}
n:n attribute, referencing from the child
------------------------------------------------------------------
class Person {
}
class Address {
List persons
}
n:n attribute, bidirectional references
------------------------------------------------------------------
class Person {
List addresses;
}
class Address {
List persons
}
I think you're just a little hung up on the relational db way of thinking. Lists in each object is the right OO thing to do. Commits and rollbacks are no problem, they happen in a transaction that commits everything or rolls back everything.
In a pure OO database such as GemStone the objects themselves have collections of references to other objects. When the object is referenced from the application the OODBMS generates a proxy that wraps the object. The schema for this is just the persisted object and its collection of references to the objects it refers to. The OODBMS does not necessarily need a link entity.
With an O/R mapping layer (assuming it is clever enough to do M:M relationships) the M:M relationship is manifested as a collection of subsidiary references on the object itself which the O/R mapper resolves to the link entity behind the scenes. Not all O/R mappers do this, so you may have a separate link object.
Do you have any particular reason you wanted to use an ODBMS? For simple data structures (such as categorizing books) you generally won't find any advantage in ODBMS over RDBMS, and in fact will have an easier time working in the much-more-standardized world of RDBMS. ODBMS has very tangible advantages when you are working with complex data types or literal persistence/storage of dynamic objects. ODBMS also is cited as being much faster and more scalable than RDBMS, though I can offer little insight into this myself. Here are a couple pages that discuss RDBMS vs. ODBMS, however:
Whatever Happened to Object-Oriented Databases
Object-Oriented Database vs. Object-Rleational Database (SO)
I would avoid data duplication because then you run into all kinds of problems with merging the differences.
the trick to this is references.
the result is that I would have each object contain a collection of references to the other object type as well as having an independent collection of the other objects.
The matching table is a relational concept, unless that intermediary connecting class may have properties that are not attributable to either of the objects. It is there as it enables queries to be written in a powerful manner as it reduces the relation to 2 one to many relations and greatly reduces data duplication. If you did this in a relation database without the matching table then things would get evil very quickly - how would an update operate? Personally i find the attraction of oo databases to be stepping away from this
the way that i would tie all the objects together is via events in code to some kind of transaction handler to allow the caching of objects states. so rather than objects manipulating each others properties they request a change through the handler and await the result in a callback.
I have two items A and B, which have a uni directional one-to-one relationship. (A has one B)
In the database these are represented by ATable and BTable, and they are linked together by ABTable. (From the database setup it appears there is a many-to-many relationship but there is not, it was done this way for normalization reasons).
The problem is due to this setup, I have only been able to get NHibernate to map this as a many-to-many relationship between the entities. Is there anyway of making the entities have a one-to-one relationship?
The best I could think of is to leave its has a many to many relationship, and then have two properties on the A entity one that returns a List of B, which would satisfy the mapping and a second non-mapped property that would get the first B from the list, to satisfy my application. - but this seems un-eligant.
Are you sure you mean a one-to-one? I've had so many people ask for one-to-one's when they really mean many-to-one's.
Anyway, short of changing your schema, the easiest thing is what you suggested; however, to make it a little cleaner, you can make the collections private so you're only exposing the two properties that fetch the first item. You can see the various methods in Fluent NHibernate for mapping private properties on the wiki.
You might try combining the join-table with one-to-one mappings in various ways. A join-table mapping permits a single class to be persisted across more than one table which have a one-to-one relationship.