moon...@posteo.org wrote:
> On 2015-03-12 09:53 Michael Bayer <mike...@zzzcomputing.com> wrote: >> which is why, “copy an object” is not an out of the box thing. Because >> nobody really wants a full “copy”, it’s something custom. > > As I described I don't want a "full copy". I only want to copy the "real > data" handled by the user. All organizing/protocol data from SQLA or > from me (e.g. the oid) as the developer shouldn't be copied. SQLA knows nothing about what data in the row is that which you care about and that which you don’t, so the names of attributes you care about have to be be arrived at in some way, either hardcoded in a list, or using an algorithmic approach as you have in your stack overflow answer. Even a primary key should not be assumed to be “protocol” data, lots of databases use natural primary keys. > The use-case is simple: > The user want to add new data which just differ a little from the last > time data was added. So it is more ergonomic to offer a new-data-dialog > with preset values from the last data-entry instead of an clean empty > new-data-dialog. In the latter the user need to type in all data again > but e.g. 80% of it is the same then yesterday. Understand? I understand completely - you have a custom copy use case where you only care about particular attributes. But what I’m hoping you also understand is that SQLAlchemy will never make a decision like this for you. You have to come up with a system on your end to identify which ones you care about and which ones you don’t. > What do you think about this solution: > <https://stackoverflow.com/questions/29039635/how-to-duplicate-an-sqlalchemy-mapped-object-the-correct-way> if it works for you, then it’s great. It’s not a generalized solution for the whole world, though. It doesn’t take into account columns that are part of unique Index objects or columns that are mentioned in standalone UniqueConstraint objects. I’d also imagine a real-world GUI attempting to present an object with default values filled in would have a lot more columns in the DB that aren’t exposed. The fact that you want to block only “PK” and single-column “unique” constraints is quite arbitrary. -- 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 sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
