warn for attributes overwritten via inheritance or otherwise

[Former user]

(original reporter: ged) A normal (simply mapped) class ignores class attributes, while an instance whose mapper inherit from another mapper uses them. I'm not sure which is correct but it should be consistent is both cases. The attached test case uses invalid values on purpose so that the difference is more noticeable (it produce a "crash" in the second case while it "works" in the first).

[Former user]

(original author: ged) and, by the way, the values seem to also be ignored (ie the test would pass) when using the multi-table/joined inheritance pattern.

[Mike Bayer]

well this seems like another one of those, "lets check for some wacky thing the user is doing and raise an error" scenarios. the mapper places class-level attributes on the class for each mapped column. if you make your mapper and compile, then overwrite the class-level attribute with your own, it'll break. that seems reasonable, right ? this example here is not much different than that except the "overwriting" is achieved through inheritance and the order of operations is slightly different...so, are you just looking for another "scan for this issue and raise error at config time" solution to this one ?

[Former user]

(original author: ged) Replying to zzzeek:

well this seems like another one of those, "lets check for some wacky thing the user is doing and raise an error" scenarios. the mapper places class-level attributes on the class for each mapped column. if you make your mapper and compile, then overwrite the class-level attribute with your own, it'll break. that seems reasonable, right ?

Indeed. The problem is that when using inheritance, there is no class-level attribute in the child class. Now that I think of it, the way it works is totally logical. As usual, it's just that it took me a while to debug my code because of that so I wanted a way for people to figure it out faster. Nevertheless, it might be a good idea to detect the simple case where an attribute already exist and to output a warning instead of overwriting it silently.

In my case, I'd have needed a check that my class variable doesn't override a parent property from the mapper, but I guess that check would be hard to achieve and probably not worth it. Sorry for the noise.

[Mike Bayer]

Looking at this test it appears to act consistently on all 0.5/0.6 versions, and in all cases the "other" attribute is taken as the mapped attribute. Its only on 0.4.8 I can get it to fail. And on that platform, its not just the dict that breaks, its str or anything else too - it mistakes the attribute for a descriptor.

[Mike Bayer]

Removing milestone: 0.5.xx (automated comment)