[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups
Jan Hudec added the comment: Confirming the fixed version linked in previous comment by Thomas Waldmann is correct and matches what `hostname -f` does. -- nosy: +bulb versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue5004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jan Hudec added the comment: Oh, I see I misunderstood Gerhard's last commit. So now the problem should be only if there is a DML statement followed by DDL statement and no commit afterwards. Well, that is indeed probably stupid. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jan Hudec added the comment: While I agree that the current behaviour is a bug (this bug), and one that renders the package unusable for me (I used apsw or different language instead), I unfortunately have to disagree with Gerhard that the change is not a problem. It can be. The implicit commit before DDL statements that is gone is not a problem, but the implicit commit *after* them that is *also* gone is. Because if somebody only does DDL statements, and upgrade script might do just that, they will now need a commit. Scripts that use dbapi2 in a portable way will have the commit, because other databases that support DDL in transactions require it already. But scripts that are only used with current sqlite and possibly mysql (behaviour of which the current version mimics) may not and will break. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jan Hudec added the comment: Ok, David, I see. Anybody who wants to use sqlite seriously in existing releases can use apsw. It is not dbapi2 compliant, but it is complete and behaves like the underlying database. I agree with Antoine and already mentioned I didn't like the current patch. I think all that is needed is another property, say `autocommit_ddl`. For compatibility reasons it would default to `True` and when set to `False` the module would then begin transaction before any command, probably except `pragma` where it is sometimes problem and should not matter in other cases and `select` still subject to `isolation_level` and possibly fix of the related http://bugs.python.org/issue9924. The second patch seems closer, but it still does not bypass the logic as I'd suggest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jan Hudec added the comment: Mike, David, The bug is that sqlite module issues implicit COMMIT. SQLite never needs this, many programs need to NOT have it and they can't opt out as isolation_level affects implicit begins only. Most programs will do some changes to data after changing the schema, so they will need to commit() at the end anyway and dropping the implicit commit before DDL statements won't break them. But there may be some rare cases that do just a create or delete table/view/index here or there that could be affected, so I am not against explicit request to stop generating implicit commits. Just put a big warning in the documentation that any new code should always do this. I don't understand why the implicit commit was initially added. It is serious problem for schema migrations and I don't see anything it would help. The only thing I can think of is to behave like MySQL which does not support DDL in transactions. But anybody who ever tried to do a non-trivial schema update in MySQL has probably cursed it to hell many times. On the other hand there is absolutely nothing broken on the implicit BEGIN (which is required by dbapi2 specification) nor on the isolation_level property which controls it. Those shouldn't be touched; there is no reason to. However note, that skipping the implicit BEGIN before SELECT only helps concurrency a little. If BEGIN (DEFERRED) TRANSACTION is followed by SELECT, the database is locked in shared mode and the same happens in the implicit transaction when the SELECT starts without explicit begin. Other readers are still allowed. The only difference is that with explicit BEGIN the database remains locked, while without it it is unlocked when the SELECT finishes (read to end or cursor closed). Oh, I briefly looked at the patch and I suspect it's doing too much. It would IMHO be best to really just make the implicit COMMIT conditional on backward compatibility flag. -- nosy: +bulb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Changes by Jan Hudec b...@ucw.cz: -- versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jan Hudec added the comment: This is somewhat borderline between bug and enhancement. The behaviour is described in the documentation and does not violate dbapi2 specification, but at the same time it is a serious misfeature and gratuitous restriction of perfectly good functionality of the underlying library. So I added all the versions back as I think this deserves fixing for 2.7, but left it as enhancement as it's not a bug per se, just a misfeature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
