One to many relationships not working in ZODB as list is mutable.They say solution is Persistent Mapping or Persistent List or BTree.Can someone please tell me how is it exactly done
I'm not sure I understand your question.
A PersistentMapping behaves just as a dictionary but is persistent. A PersistentList is just a that, a list that is persistent.
A BTree behaves also as a dictionary but it's optimized for huge numbers of objects. You shouldn't use PersistentMapping or PersistentList if you have to deal with many objects.
For ZODB relations you can use object references as you would normally do in Python.
ZODB even supports weak references if you need them.
There are other specialized packages, like z3c.relationfield, to deal with relations in ZODB, like for example if you need to search by relation but I never had the need to use them.
Related
There is one question that I often ask myself while designing a program, and I am never quite sure how to answer it.
Let's say I have an object with multiple fields, amongst which there is one serving as the identifier to that specific object. Let's also say that I need to keep track of a List of such objects somewhere else.
I now have three, and probably even more, options on how to go about it:
Have my object contain its own identifier, and all its other fields. I now use a simple array (or whatever simple list collection) of my objects where I need it. When I am looking for one specific object, I loop through my list and check for identifier equality.
Pros: 1. "Clarity" for each object instance. 2.?
Cons: Manipulating a collection of these objects gets annoying
Have my object contain all fields beside its identifier. I now use a Map with identifier as key, and object as value. When looking for one specific object, I just lookup the identifier in the map.
Pros: easy lookups and insertions,?
Cons: object instance itself doesnt know what it is,?
Combination of both: use a map with identifier as key and object having its own identifier as a field as value.
Pros: mentioned above.
Cons: looks redundant to me.
What situations would call for what? Let's use the standard hello-world example of networking for example, a chat server: how would I handle multiple "groups/channels" people are in?
What about other applications?
Your question is very wide and, actually, contains two questions.
First is “Which data structure is better — dictionary or list?”. The answer is: it depends on performance you want to achieve on insertion and search operations. Basically if you need to look through the collection, then list is ok, and if you need to have fast look-up, then dictionary is better. Dictionary has more memory overhead than list.
The second is “Do I need to have an Id field inside an entity or can I use built in hash code?”. The answer is: it depends on how you will use your object. If you want Id just to store it in a dictionary, then, most likely, you can go with hash code. There is nothing wrong with storing Id of an entity inside that entity. Either you use Id or hash code, you need to be sure that this entity will be uniquely identified by id or hash. That's the main concern with it.
You can override GetHashCode method and make it return Id of your entity. Sometimes you can find such implementation when hash code is required for collection and Id is required for database.
So, it really doesn't matter what you will choose in the end if both approaches are working for you right now.
A map<Identifier, Object> will offer you O(1) performance when retrieving an object based on its identifier. There certainly are situations where you want to achieve that.
However, in other cases it might be redundant to use this approach. It all depends on the situation at hand.
Two guidelines may answer this question:
A use case that calls for a lookup where there is an expectation of a 1:1 relationship between the key and value implies a Map structure.
OOP implies that a key which is so closely related to an object as to preform a lookup should be encapsulated within that object.
Regarding the question of redundancy, consider the key in a map is nothing but an index. Indexes are as common in data as in books.
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)?
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'm considering using Core Data for an app I'm writing. However, after reading the docs I'm unsure how to model a particular relationship. Here's the basics:
I have an Entity called "ProjectFile" that has some basic string properties. (One of those is a path to a file on disk -- call it "File X" -- that my app is going to manipulate.) However, when the app manipulates file X, it may also need to manipulate OTHER files --- fileY and fileZ.
FileY and FileZ, like fileX, will be "ProjectFile" entities. So I need a way to tell Core Data "FileY and FileZ are associated with FileX." To do that, I created a relationship on the "ProjectFile" entity called "linkedFiles" and set the destination to "ProjectFile" and the inverse to "linkedFiles". I then set this as a "to-many" relationship, as each "ProjectFile" may have multiple linked files.
This seems recursive to me and I'm not sure I've done it correctly. The "linked" files (fileY and fileZ) need to exist on their own, just as fileX does. I need to be able to "delete" them from the "linkedFiles" relationship but still have them exist separately, if that makes sense. Essentially, I just need a weak relationship between separate objects in my model.
Have I done this correctly, or am I missing something? Thanks!
So, you have a data model that looks something like this:
ProjectFile{
path:string
infile<<-->>ProjectFile.infile
}
This will work because (1) Core Data relationships have directionality/cardinality and (2) each object is unique. Where you can get into trouble is with delete rules. You pretty much have to use No Action or Nullify in this circumstance or risk setting off a cascade delete. That in turn runs the risk creating orphaned objects that have no relationships and are hard to find and remove in the object graph.
A better model would encode more information in the relationships themselves. It appears that the real-world file objects you are modeling have two separate relationships to other file objects: (1) Each instance has other instances that it manipulates and (2) each instance has other instances that manipulate it. So, your model should reflect that:
ProjectFile{
path:string
toManipulateFiles<<-(nullify)->>ProjectFile.manipulatedByFiles
manipulatedByFiles<<-(nullify)->>ProjectFile.toManipulateFiles
}
This makes explicit the type relationship between the objects and lets you quickly and easily get the right objects for any particular operation. You can use Nullify on one relationship without orphaning the object on the other.
Although it isn't immediately obvious, relationships aren't just lines on a graphical model, they are actual live objects that can carry a lot of information. You need to design with this in mind.
Django doesn't support displaying of related objects from a many-to-many relation in the changelist for a good reason. It would result in a lot of database hits.
But sometimes it is inevitable and necessary to e.g. display an object's categories, which have a many-to-many relation to the object, in the changelist. Given that case, does anybody have some experiences/snippets etc. to speed this up a little (thinking of caching, custom sql queries...)? (I am aware of the fact that I can make a method that calls object.categories.all()... But this can really be a pain in the ass...).
Here you have to make a choice about denormalization in your model if you think that one more database hit per row in your changelist is unacceptable.
The question is how to store this ManyToMany relation ? Maybe you can go with a synced JSON serialized object in a CharField or a TextField to serialize the subset of fields you need (pk and name for instance).
But be careful with the side effects on performances when adding a potentially big column, the queryset's defer method is your friend.