All in the title :)
I like to understand what is the Cascade Detach thing? I can understand what is a Cascade Remove or something.
Thank you
It's all about associations.
Lets say you have two classes Parent and Child with OneToMany association between them. Cascading operation mean that if you are detaching/removing object at the owning side of the association, objects on inverse side are also detached/removed.
Note that this has nothing to do with SQL On delete/update cascade, this applies only to PHP data model. But, of course, when it comes to flushing changes, entities that were removed from data model with cascade operations are removed from DB just as well as manually removed entities.
Related
I have a Lessons Model, and I have a Challenges model. Right now they are related with foreign keys. So 1 lesson can have multiple challenges. My problem is that I want to re-use the Challenges objects in other lessons, but sometimes with very slight changes in the given challenge object. Up until now, I have just copied the challenge object, slightly changed it, and used that for the new lesson. The problem with this is that the database gets polluted with a bunch of similar objects, making it hard to scale with many lessons.
If you want to associate a challenge to multiple lessons, you need to use a many-to-many relationship instead of a foreign key. If the changing fields are always the same, a through model can be used to contain them. If you change multiple fields you are probably already using the best solution.
I have some code that consists of 3 models, namely Course, Section and Lecture.
A Course has many sections, a Section has many Lectures. Say i want to retrieve all the Lectures that belong to a particular Course, Course also has a property called 'title' so thats what will be used to filter. According to the tutorial i'm reading i should do this to get the lectures:
Lecture.objects.filter(section__course__title = "title of course)
This is pretty straightforward but what i'm wondering is how django is handling this under the hood. Some joins must be involved i can imagine, but according to the answer of this thread Does Django support JOIN? Django cannot make Joins.
But when i look at the links he provides i can read that django does handle joins behind the scenes.
So lets assume django does handle joins, how does it know when to make a left join or a regular join? A regular join can only be made when it is certain that every parent model has a reference to a child model, the field is marked not null. If it can be null then a left join should be used. Is django intelligent enough to know when to make which join?
Thank you
The django ORM will be performing the join operations for you under the hood it abstracts away a lot of the complexity.
If you run the code below should will be able to see the SQL which django generates.
quseryset = Lecture.objects.filter(section__course__title = "title of course")
print(queryset.query)
It is explained in the django docs: Lookups that span relationships
I'm writing my own adapter/serializer. In order to send data to backend, I have to detect changes in DS.Snapshot and original Ember object. For ordinary attributes, it is possible to changedAttributes() but I did not found a way how to detect changes in hasMany relations.
I can detect new relation using snapshot.hasMany('foo') and changedAttributes(). But this approach is not able to find deleted relations.
Ember (2.x) does not track relations (e.g. hasMany) but it is possible to use ember-addon ember-data-change-tracker that can almost do it. It allows you to (auto-)save the current state of relations and afterwards you can compare this 'saved' (=old state) with the current state. You have to find a difference by yourself. A simple example from adapter:
snapshot.hasMany('users').length <-- current count of relations
snapshot.record.savedTrackerValue('users').length <-- old count of relations
Thanks to Christoper for pointing me to the right direction.
I've seen this answer, so perhaps it's Django's behavior that I'm not understanding, or perhaps I changed something myself without realizing it, but, after deleting several instances of a table (perhaps I deleted the parent instance and ON DELETE CASCADE occurred), I found that the automatically-generated IDs of other instances in that table had changed. I believe that I'd called .delete() on the models. Would Django ever do this? The database was Postgres.
I have no evidence that this was the case, but I'll guess that human error was involved in order to close the question.
I'm trying to understand the purpose of Django Intermediary Models.
Conceptually, they seem to be equivalent to association classes in UML class diagrams. Is there any fundamental difference between the two that I should be aware of?
In spite of the apparent similarity, I've found several resources explaining the purpose of intermediary models, but none of them made any reference to "association classes", which makes me somewhat suspicious.
You're not likely to find any comparisons with UML diagrams in the Django literature - UML modelling isn't really a big thing in the Python world, in my experience.
But looking at your diagram, I'd agree that the concept does seem very similar. Don't forget that the ORM is just that, a mapping of relational concepts onto objects: in this case, the through table maps the intermediary table that is always created in a many-to-many relationship. The only difference is that you only need to specify it manually if you want to add extra information to that relationship, like the enrollment date in your link. If you don't need the extra fields, you don't need to specify the intermediary model, but the table still exists, containing just the foreign keys to each end of the M2M relationship.
They're used to store additional data about a many-to-many relationship. I'm sure this is blasphemy, but I think the best example is from the Ruby on Rails guides, which uses the association between patients and doctors. A doctor has many patients through appointments; a patient has many doctors through appointments as well; but you can't model this relationship directly, because an appointment also has a date and time.
I think you are right that conceptually, they server a similar purpose to association classes in UML.
This is how many-to-many relation is to be implemented in any relational database, it is a fundamental part of relational database design. So I suggest to learn about database design principles first because knowing how database works is necessary for using ORM properly anyway.
wikipedia on Many-to-many