I also looked at this through SQLite database browser, and the database is
correct, so is this a Python side error?
--
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
Il 09/08/11 02.42, Aviv Giladi ha scritto:
Dear Stefano,
First of all, thank you. Allow me to express how much I appreciate
your time and assistance - you and your colleagues are making the
technology world this much better by being so attentive and helpful!
Thank you.
Therefore I chose
Stefano,
Thank you again for your time. I am sorry for not posting my actual
code - it is sensitive, therefore I am trying to reproduce the same
issue with different code.
In my __init__ function of my Rating I am setting 3 members that are
objects like so:
self.member = member
These members
Il 08/08/11 22.53, Aviv Giladi ha scritto:
Dear Stefano,
I have been able to create a reproducing project. I am sending it to
you directly because I was unable to figure out how to attach the test
file to the message board. I will post our findings there once we are
done.
The included
Il 07/08/11 00.35, Aviv Giladi ha scritto:
Everything works great when I create and assign all 3 subratings to
the rating object before I add it to the session.
However, I need to be able to create a Rating that only has 1 or 2
subratings, and the other subratings absent.
When I do that,
I see.
Where can I start looking for such an error? What could possibly be
causing this?
On Aug 7, 6:51 am, Stefano Fontanelli s.fontane...@asidev.com wrote:
Il 07/08/11 00.35, Aviv Giladi ha scritto:
Everything works great when I create and assign all 3 subratings to
the rating object
Il 07/08/11 20.08, Aviv Giladi ha scritto:
I see.
Where can I start looking for such an error? What could possibly be
causing this?
I'm sorry but I cannot help you without your code... not a similar code
but THE code which produce that error.
Regards,
Stefano.
--
Ing. Stefano
Il 06/08/11 00.32, Aviv Giladi ha scritto:
Hi Stefano,
I create and add a Rating and Subrating (both end up in the DB no
problem).
Then, I call session.delete(rating_obj) and commit it. I look at the
DB, and the Rating is gone, but the SubRating is still there.
The DB shows that the Rating has
Stefano,
Thanks! Your script helped me narrow down the problem.
My Rating object has multiple Subrating objects. So in my real code, I
have something like:
class SubRating1(Base):
__tablename__ = 'subratings1'
id = Column(Integer, primary_key=True)
name = Column(Unicode(32),
Il 04/08/11 21.27, Aviv Giladi ha scritto:
Hey,
Tried adding cascade to Rating's backref call like so:
subrating = relationship(SubRating, backref=backref(rating,
cascade=all, delete-orphan
uselist=False))
This unfortunately doesn't work - when I delete a Rating, the
according Subratings
Hey Stefano,
I tried that, but when I did, this is the error I got while inserting
a new rating:
InterfaceError: (InterfaceError) Error binding parameter 0 - probably
unsupported type. u'SELECT subratings.id AS subratings_id \nFROM
subratings \nWHERE subratings.id = ?' (symbol 'NEVER_SET,)
On
Il 05/08/11 20.38, Aviv Giladi ha scritto:
Hey Stefano,
I tried that, but when I did, this is the error I got while inserting
a new rating:
InterfaceError: (InterfaceError) Error binding parameter 0 - probably
unsupported type. u'SELECT subratings.id AS subratings_id \nFROM
subratings \nWHERE
Hi Stefano,
Thanks! The code is just like this:
subrating_subratingproperty_association =
Table('subrating_subratingproperty_association',
Base.metadata, Column('subrating_id', Integer,
ForeignKey('subratings.id')),
Column('subrating_property_id', Integer,
Hey,
Tried adding cascade to Rating's backref call like so:
subrating = relationship(SubRating, backref=backref(rating,
cascade=all, delete-orphan
uselist=False))
This unfortunately doesn't work - when I delete a Rating, the
according Subratings are NOT removed.
What am I doing wrong?
Il 30/07/11 23.24, Aviv Giladi ha scritto:
Sorry, but I am really confused.
Are you guys saying that on SQLite for example, cascade deletes don't
work at all? Or do they work, but are less efficient?
ONUPDATE/ONDELETE cascade - SQL expression: on SQLite and MySQL MyISAM
doesn't work at all.
Thank you for your response.
In that case, how do you manage these kinds of situations in SQLite
and other engines in MySQL?
Do you manually delete the children as well?
On Jul 28, 10:35 am, Stefano Fontanelli s.fontane...@asidev.com
wrote:
Il 28/07/11 01.15, Aviv Giladi ha scritto:
Hi,
I
SQLAlchemy's cascade='all, delete-orphan' implements the same CASCADE
functionality as ONDELETE does, in Python. It is just less efficient since
collections need to be fully loaded into memory for them to be processed.
On Jul 30, 2011, at 1:49 PM, Aviv Giladi wrote:
Thank you for your
Sorry, but I am really confused.
Are you guys saying that on SQLite for example, cascade deletes don't
work at all? Or do they work, but are less efficient?
Thanks again!
On Jul 30, 11:08 am, Michael Bayer mike...@zzzcomputing.com wrote:
SQLAlchemy's cascade='all, delete-orphan' implements the
Il 28/07/11 01.15, Aviv Giladi ha scritto:
Hi,
I am actually using both MySQL and SQLite (one on the dev machine, one
on the server).
Does that make a difference?
ONDELETE and ONUPDATE don't work on SQLite and MySQL MyISAM.
You must change your database to test them.
In MySQL you can create
Hi,
I am actually using both MySQL and SQLite (one on the dev machine, one
on the server).
Does that make a difference?
On Jul 27, 12:26 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jul 25, 2011, at 9:47 AM, Aviv Giladi wrote:
I can't seem to make cascade deletes work in
Your assumption should be correct.
http://www.sqlalchemy.org/docs/05/reference/orm/mapping.html#sqlalchemy.orm.relation
On Tue, Sep 8, 2009 at 6:40 AM, Eloff dan.el...@gmail.com wrote:
Hi,
I see cascade='all, delete, delete-orphan' in the tutorial, but I
thought I read in the docs
D'OH! (slaps head)
Thanks for pointing this out, it makes perfect sense.
I got it working by getting it from the DB, and merging it into the
current session, then deleting:
def DELETE(self,dmemberid):
x = MemberInfo()
memberProfile = x.GET(memberid=dmemberid,raw=True)
merged_obj =
Gloria W wrote:
D'OH! (slaps head)
Thanks for pointing this out, it makes perfect sense.
I got it working by getting it from the DB, and merging it into the
current session, then deleting:
def DELETE(self,dmemberid):
x = MemberInfo()
memberProfile =
Thanks for taking the time to respond. I still get an error, please
see below.
I show the record, just after a successful insert. I then show the
error on delete.
When I go into the db and manually delete these records, they exist as
expected, and the deletion is successful.
Thank you in
this operation is illegal:
def DELETE(self,memberid,fields=None):
memberProfile = MemberProfile(memberID=memberid)
self.session.delete(memberProfile)
you must load MemberProfile from the database or merge() the above
object into the session.
On Feb 2, 2009, at 4:11 PM, Gloria W
use all, delete cascade but not delete-orphan.
On Jan 28, 1:06 pm, Gloria W strang...@comcast.net wrote:
Hi again,
I have a problem with a cascade relation. Any help or clues would be
greatly appreciated.
I have a model which has this relation:
member =
i think i had similar configuration, and i did it like one link was
using default cascading, the other was just 'all'. but i'm not sure
if yours is same, and any way i got mine via trial and error.
do play with the cascade options. also i'm not sure if u apply some
cascade on a backref what
Is it planned for 0.6? or earlier?
Anyway thanks: I stop trying all the combinations right now! :)
On 15 jan, 18:30, Michael Bayer mike...@zzzcomputing.com wrote:
There's various error conditions we should have added in 0.5 but have
not. We should look into raising warnings in 0.5 and
i just committed the two warnings just now.
On Jan 15, 2009, at 12:49 PM, GustaV wrote:
Is it planned for 0.6? or earlier?
Anyway thanks: I stop trying all the combinations right now! :)
On 15 jan, 18:30, Michael Bayer mike...@zzzcomputing.com wrote:
There's various error conditions we
What is the best way to achieve the auto delete of the child then
(refering to the example earlier)? I think about using an attribute
extension...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To
ondelete and onupdate are keyword arguments within ForeignKey()
itself, and they come out as part of the DDL when you call
metadata.create_all().
On Dec 23, 2008, at 8:42 PM, justmike2...@gmail.com wrote:
I seem to be running into a problem with implementing cascades in
sqlalch. Next to
Yea I do the ondelete and onupdate in ForeignKey, creates tables and all but
does not do the cascade or at least not in MSSQL.
On Tue, Dec 23, 2008 at 7:42 PM, justmike2...@gmail.com
justmike2...@gmail.com wrote:
I seem to be running into a problem with implementing cascades in
sqlalch.
generates the ON DELETE CASCADE in the DDL, versus the cascade does
not work, are two different issues. Which are you experiencing, and
if the latter, how is the issue manifesting itself ? Can you produce
sample code which reproduces your issue ?
On Dec 23, 2008, at 10:19 PM, Michael
code:
queue_table = Table(
'QUEUES', metadata,
Column('QUEUEID', Integer, autoincrement=True, primary_key=True),
Column('JOBNUM', String(48), ForeignKey('JOBS.JOBNUM',
onupdate=CASCADE, ondelete=CASCADE)),
Column('SCHEDID', String(48),
On Thursday 25 September 2008 04:30:19 Michael Bayer wrote:
On Sep 24, 2008, at 6:23 AM, [EMAIL PROTECTED] wrote:
hi
i have cascade= option of relation switched automaticaly between
all and other values, and nothing. so i used cascade=None as
nothing, hoping it will get the default
On Sep 25, 2008, at 3:03 AM, [EMAIL PROTECTED] wrote:
I didn't think we had too much public API with the default=False
thing going on but I havent taken a poll.Usually these defaults
should just be documented. A symbol like DefaultValue might be
nice except I don't see how that's any
On Sep 24, 2008, at 6:23 AM, [EMAIL PROTECTED] wrote:
hi
i have cascade= option of relation switched automaticaly between all
and other values, and nothing. so i used cascade=None as nothing,
hoping it will get the default behaviour. the result was some query
got 6x slower (actualy thats
On Thursday 28 June 2007 16:16:09 znerol wrote:
Hi All
Yes, i know, there is a FAQ-entry and i realized that this issue
was discussed before. Regretably i'm not able to make things work
with a one-to-many relationship using cascade=all, delete-orphan.
Now i discovered that even the example
On Jun 28, 2007, at 9:16 AM, znerol wrote:
Hi All
Yes, i know, there is a FAQ-entry and i realized that this issue was
discussed before. Regretably i'm not able to make things work with a
one-to-many relationship using cascade=all, delete-orphan. Now i
discovered that even the example
Hi Again
I was able to track down the issue. If the addresses attribute is
replaced with a newly generated list containing all the items from
the old list sqlalchemy apparently thinks that the elements are to be
deleted (because the list was replaced) and marks them as orphan.
Same
http://www.sqlalchemy.org/trac/wiki/
FAQ#FlushError:instancesomeinstanceisanunsavedpendinginstanceandisanorph
an
I think this is not Andreas an I too are searching to explain.
The documentation is correct, and infact in tg-admin all go
perfeclty.. but when the same example is gone from TG
--On 16. Mai 2007 13:45:21 -0400 Michael Bayer [EMAIL PROTECTED]
wrote:
new to the FAQ:
http://www.sqlalchemy.org/trac/wiki/
FAQ#FlushError:instancesomeinstanceisanunsavedpendinginstanceandisanorph
an
The FAQ does not explain the problem. Look at the real code:
def
--On 17. Mai 2007 10:16:17 +0200 Andreas Jung [EMAIL PROTECTED] wrote:
--On 16. Mai 2007 13:45:21 -0400 Michael Bayer [EMAIL PROTECTED]
wrote:
This code causes the trouble. There is no save() operation involved - just
a flush() operation driven by the Zope transaction integration of SA.
On May 17, 2007, at 4:16 AM, Andreas Jung wrote:
The FAQ does not explain the problem. Look at the real code:
def importImagesFromFilesystem(self, lidx, imgdir):
Import all images from a local filesystem into
the staging area of the Medium.
# get
On 14 Feb., 01:02, Michael Bayer [EMAIL PROTECTED] wrote:
OK its fixed in r2314. the cascade from User.meta does take effect,
This was fast !
I checked out r2314, and my old code (without delete-orphan) is
working now.
The only problem: I started to write a little beginners manual for the
On 12 Feb., 18:17, Luke Stebbing [EMAIL PROTECTED] wrote:
Right, delete-orphan is what adds the lifecycle relationship between
parent and child. It means that the child can't exist without a
parent. That lets SA know that it should eliminate the child rather
than trying to null out the
OK its fixed in r2314. the cascade from User.meta does take effect,
its just that the combination primary key/foreign key column on the
t_userdata table was being blanked out when the deletion of the User
took place, i.e. it was not checking first that the Userdata was also
being deleted.
Right, delete-orphan is what adds the lifecycle relationship between
parent and child. It means that the child can't exist without a
parent. That lets SA know that it should eliminate the child rather
than trying to null out the relationship.
You probably want all so that all actions performed
See http://www.sqlalchemy.org/docs/
datamapping.myt#datamapping_relations_lifecycle
I think you want a parent-child relationship between User and
Userdata. Here's how I would change it (disclaimer: I'm new to SA
myself):
class User(object):
pass
class Userdata(object):
pass ### we'll
Luke, your example is a great speed-up for me learning SA ! And my
code is working fine now.
I' m still looking what exactly makes the AssertionError disappear.
(Well, your other changes (uselist=False etc.) are clearly an
improvement. Still want to find out the cause of the error)
The minimum
the orphan detection only supports one parent at a time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this
i doubt this was any faster in previous releases since the basic
metholodgy of cascade hasnt changed; when you attach object B to object
A, it cascades the save-update operation across the entire graph
represented by B. While there was one little fix a while back so that
it wouldnt do cascade if
Michael Bayer wrote:
i doubt this was any faster in previous releases since the basic
metholodgy of cascade hasnt changed
Probably wasn't, I've just been testing with larger data sets lately.
so ive added your test with an extra assertion that the session in fact
contains 611 instances to
well things like this, i.e. cascade not going over the same field of
objects over and over again, are big and obvious. smaller things, its
mostly the attributes package that adds the overhead in...i put that
package through a huge overhaul some versions ago to simplify it, and i
ran it
Daniel Miller wrote:
Lately I've been noticing severe slowness when instantiating new SA
objects...
Oh yeah, I forgot to mention that many of my class constructors take a parent
object as one of their arguments, which explains the slow instantiation.
cascade_test.py demonstrates that the
55 matches
Mail list logo
