On Wed, Nov 8, 2017 at 1:58 PM, Sven <[email protected]> wrote: > What do you mean by "deduplication" ?
it means if you have a collection : [a, b] and you try to add "a" again: collection.append(a) you get: [a, b] that is, "append" is idempotent given a particular object identity. > > I have certainly just a few exotic different type of collection. The others > are standard (lists, dictionaries, ordereddict, etc), but I don't understand > why you are asking that :p all of those except "list" feature idempotent additions already. > > Are you asking that because you think that the solution would be to always > use collections that can't contain duplicate (like set) ? So for example, I > could make a list class and just overide the append method to avoid > duplicate ? yes. Also, with some time to think about my answers, I can give you a better explanation why you not only *need* to use backrefs but you also need deduplicating collections. your use case is: child.parent = p parent.children.append(p) your issue is that with backrefs, the append() adds "p" twice. So let's assume that doesn't happen. Now lets add the context that your two operations are far apart. If we perhaps had this: child.parent = p # things happen.... such as: session.commit() # elsewhere in the code parent.children.append(p) Above, we again would have "p" in parent.children twice, if client-side deduplication is not present. This because the relational database, unlike a pickle file, *does not have uni-directional associations*. Unless there is a much more complicated table structure under the hood, it is not possible to have "child.parent == p" and "p not in parent.children". That's why the backref was created in the first place, so that an object relationship can behave like it would after it's flushed, without needing to insert the row and re-select it immediately. Additionally, it is not possible for parent.children to contain the "p" instance more than once in the database itself, again unless there is a much more complicated table structure taking place behind the scenes. If you appended "p" five times to parent.children , persisted it, and then reloaded fresh, if this is standard one-to-many, you only get the "p" identity once. Both of these rules have to do with the basic geometry of how row associations work in relational databases, that is, they are based on the concept of the foreign key. Except in the case of many-to-many, there is no separate "collection" table present that would indicate a unidirectional association or multiple associations of the same object. The fact that relational databases don't have unidirectional or multiple associations, whereas in a "serialized object file" or object database these are the default, is one reason why it's not practical to assume the object model can be completely separated from its persistence style. > > -- > SQLAlchemy - > The Python SQL Toolkit and Object Relational Mapper > > http://www.sqlalchemy.org/ > > To post example code, please provide an MCVE: Minimal, Complete, and > Verifiable Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
