Hi all,
We have a list of polymorphic objects from which delete object does not
work, not matter what we try.
The situation:
class ItemGroup(Base):
__tablename__ = 'item_group'
__table_args__ = (
UniqueConstraint('model_id', 'item_group_color_id',
Thank you very much for your answers!
Some more questions
1) I see you use sa.inspect(self).dict in __getstate__. Is it safe to
replace it with self.__dict__? I didn't find any difference in the result,
but __dict__ works 30 times faster.
2) I'm going to implement __getstate__ and __setstate__
A bit of advocacy from my side on cx_Oracle:
https://github.com/oracle/python-cx_Oracle/issues/365
Mike, there's something you might want to look at. We have this monkey
patch on SQLAlchemy in our recent code, which was necessary to get the
correct behavior for NCHAR columns.
from
On Fri, Oct 11, 2019, at 3:56 PM, Victor Olex wrote:
> A bit of advocacy from my side on cx_Oracle:
> https://github.com/oracle/python-cx_Oracle/issues/365
>
> Mike, there's something you might want to look at. We have this monkey patch
> on SQLAlchemy in our recent code, which was necessary
I've considered manual queries and building classes by myself. This option
is good in terms of performance, but it requires a lot of code duplication
and kills code reuse. So I want to use the same mapper classes for both
read and modify operations. Also, I want to have the same query
On Fri, Oct 11, 2019, at 5:23 AM, Александр Егоров wrote:
> Thank you very much for your answers!
>
> Some more questions
> 1) I see you use sa.inspect(self).dict in __getstate__. Is it safe to replace
> it with self.__dict__? I didn't find any difference in the result, but
> __dict__ works
You haven't given a complete script to reproduce the problem, so I'm
not certain what happened. The following is just a guess
You are using query(...).delete() with joined-table inheritance, which
has a lot of caveats in the docs:
Hi Simon,
Thank you for your reply.
I've tried all the variant I could think of, also eg for item in items:
session.delete(it),
with and without remove on the list of items, all known mapper and relation
params but nothing.
However, I've tried a similar structure from examples from the web and
I am using alembic with Snowflake.
In terms of DDL migrations I need to cater for SECURED VIEWS, it is pretty
trivial to extend ReplaceableObject to deal with this.
The other thing I am finding is that Snowflake insists that DROP FUNCTION
be provided with a list of the argument types along
I think it would be simplest to use a regular expression to pull out the symbol
names from the declared function in order to write out the DROP text.
Otherwise, just add additional arguments to ReplaceableObject. It's a recipe so
you should change it directly, I wouldn't create new superclasses
10 matches
Mail list logo
