[sqlalchemy] Re: creating tables dynamically
That shouldn't be too hard... When creating a Table as shown in the tutorial, you can provide any number of columns. You can later modify an existing Table object; there's an append_column method. See: http://www.sqlalchemy.org/docs/reference/sqlalchemy/schema.html#tables-and-columns Nebur -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: is there any sort of find_or_create query?
AJ, thanks for the monologue ;-) It reads like a good overview. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: session (autocommit/not autoflush) + begin dirty
Are you sure ? Did you check that really nothing happened in the DB ? (Sorry for the distrust ;-) I'd expect myself to miss such a check sometimes, e.g. when it's late in the evening...) And which SA version do you use ? I experience that SA 0.5.6 issues a correct sequence of: BEGIN UPDATE ... COMMIT when I call session.begin(). (This happens with both new and dirty objects (probably deleted,too) the same way.) Ruben -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: session (autocommit/not autoflush) + begin dirty
If you like, I'd run your test in my environment (Py2.5,MySQL or SQLite). Can you mail it or put it to something like pastebin ? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: Session-related best practice advice
This solves my case. Bummer I've found that out just now. Anyway, thought this post might help a bloke or two... No need to worry, should help some blokes mainly because that design decision usually is not self-evident (single session for multiple threads contra a session-per-thread will (rawly) mean: locking at application level contra DB level locking - and when the tables are exclusively for your application, you have the free choice.) So if the one session per thread- way should turn out to be bad - please post a followup, to help even more blokes ;-) --~--~-~--~~~---~--~~ 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 group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Session-related best practice advice
Did you already consider using an orm session per thread ? That practice would be supported well (see contextual/threadlocal sessions). Ruben --~--~-~--~~~---~--~~ 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 group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Should we separate business logic and ORM mapping classes.
A good question. I think we agree that both ways can work well... Usually, I do prefer the less OO style. In your example, a pure mapping class and business logic in a user manager. The main reason is that what you call OO style seems to enforce a lot of arbitrary decisions. For example, when you bind an EMail object instance to a User object instance. Where to put the addXXX() method - into the User, or into the EMail ? (I see that ugly question appear repeatedly, e.g. in the language design. Do we want str.to_int() or Str.from_int() or int.to_str() ... etc...) Also notice that the OO style is not necessarily a pythonic style (which may also be desirable). Let's look out for examples: Python design prefers even to use a global len() function instead of str.len() etc. (hm, I don't like especially that case, but I think GvR also may have had its good considerations.) Or consider sqlalchemy-ORM where most functionality is in the orm-session. Other orms (SqlObject etc.) prefer to put methods into the mapped classes (i.e.Active Records). The sqlalchemy design may also have other reasons (e.g.unit-of-work is wanted). But indepently from collecting actions in a unit-of-work, the design with methods in the session -not in the objects- feels well. (Sadly, this is more gut feeling than rational.) I think these design question is fundamental, and a lot of gurus already have written about OO for decades now. Should there really be no guru article, and no forum discussion about that ?? I'd also appreciate anyone showing me what knowledge already exists here. --~--~-~--~~~---~--~~ 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 group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: parent/child relationship: what am I doing wrong?
Kevin, did you already look at http://www.sqlalchemy.org/docs/05/mappers.html#adjacency-list-relationships ? By default, as the doc says, one-to-many is assumed. You want the backref (parentdir) to be a scalar, so you probably have to specify remote_side. Ruben --~--~-~--~~~---~--~~ 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 group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] programming style | using sessions
Hi folks, SA 0.5 behaviour changes like the new auto_expire_on_commit made me re- think about the session usage style. I've always used to use fresh sessions for each small job to be done. In fact, a session was used nearly similar to a transaction; after any atomic operation, it is usually clear()ed or even close()d. Only in very few places, a session was used for subsequent operations which don't need to be atomic. Nearly as a matter of routine, any commit() was followed by some clearing operation, usually clear() (aka expunge_all) or even close(). (expire_all might have been good enough in most cases - but clear() looks like beeing on the safe side.) The reasons for that style of very short-living sessions were - before each operation, I anyway have to ensure the required objects (or the right parents) are add()ed into the session. It's most simple to always assume the objects must be added. - sessions that were not clear()ed often did blow tests in non- reproduceable ways, obviously by containing stale data. As I said, some things have changed with current SA. By default, each commit expires the session. Even a rollback does not categorically damage the session (whow!) There might be reasons for other session usage styles, e.g. let a session live longer for performance reasons. I'd be grateful to read how other programmers use the session objects, especially whether the session object does live longer (or is even continued to be used after a rollback ?) Ruben --~--~-~--~~~---~--~~ 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 group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Best practice for immutable object structures
On 2 Jun., 15:19, [EMAIL PROTECTED] wrote: how would u assure that noone changes these objects? it should be considered a programatical error, so throwing an exception might be appropriate. i have such concept in dbcook, and it is implemented (so far) via an assert in MapperExtension.before_insert(). That's right (althought another topic). It is surely good style to assure this. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Best practice for immutable object structures
im assuming the performance increase is due to the reduced overhead in creating objects ? From what I can see, you are still issuing SQL, still processing result rows, still populating state in the given instancesall of which is very time consuming. Plus, your scheme actually wont even save object creation overhead since you can't exactly do it that way... That's right: The queries are the same when no futher optimization is applied. Object creation surely is very fast when compared with queries. But there have been two intentions: Performance, and object identity. Performance is not significantly improved by saving object creation. But the results of some performance critical methods are cached, thus saving a huge amount of queries. This caching in turn relies on the constant object identities and would be tricky if the objects would change their identity. So, the performance improvement is an indirect effect. The object identity simplifies (at least) this task. this wont work out of the box because a particular object instance can only be in one Session at a time. For this kind of use case we provide a method called merge() which takes a dont_load=True argument to create local copies of objects in sessions. Yes, the custom identity map cannot be a sessions identity map, it is a plain dict. Otherwise, the objects indeed would have to be merged in any new session. But copies of the objects, anyway, are not desired since identity is to be kept. why not session.new ? context.uow.new is gone in 0.5. Thanks. ouw.new indeed did not look adequate. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Best practice for immutable object structures
On 2 Jun., 18:22, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 2, 2008, at 11:55 AM, Nebur wrote: sosince these objects are returned by create_instance(), that means they are getting sent straight into a Session. I'm assuming you didn't write your own Session, so what happens when the populate_instance() step gets run on the objects , and several concurrent threads are all issuing populate_instance() on those items There are more places where multiple threads would fail. E.g. caching the instances. The concerned web app will not use multiple threads (but single- threaded processes only.) So, a threadsafe pattern was simply not intended. I should have placed this prerequisite prominently above the recipe. modifications. Similarly, I dont see how very basic functions necessary for SQLA's operation, such as object_session(), can possibly work correctly here, since you are attempting to place the same object in multiple sessions - an object's session is identified by a single attribute placed upon the object's state (in 0.4 its on the object itself). Unless your app is using only one Session. Then it could work, It's ensured that there won't be two or more sessions same time. (Beside that, I do _not_ want to enforce a session to live long; I think that's not the intention of an ORM session. I've assumed that generally, an application better should not depend on very long-living sessions, althought it might be technically possible. So, the sessions will change but strictly sequentially and not overlapping.) If there is some central core of state that you dont want to replicate, it's still possible to have many copies of an object all reference that same state using a proxying pattern. As far as hash identity, the __hash__() and __cmp__() methods work fine in that regard. Yes, another approach would be accepting copies of the immutable objects with appropriate hash values. The question was: which version does represent the real world best ? I think in the case of immutable (readonly) objects, representing these as long-living instances does look adequate. These objects would change states between persistant and detached when bound and unbound with subsequent sessions. Of course, what I want to clearify is: Are long-living objects a design against the ORM ? Is the subsequent change between persistent and detached state an anti pattern (even if we can make it work) ? Obviously, there's nothing wrong with detached instances that get persistent again, as the docs say. But here, I'm aware that the objects to not take the usual session.update() way. If this is against the ORM intention, or in some unspecified grey area, I'd clearly withdraw the pattern. Otherwise, i'd prefer the pattern since it seems to picture the real world well (and even does substantiate this by simplfying tasks in different places.) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Best practice for immutable object structures
On 2 Jun., 17:22, [EMAIL PROTECTED] wrote: if i get it right, u make some map in memory of that terra incognita of those untouchable readonly objects, and then use it ? so why not just build all that _once_ into some structure of non-DB objs, and then throw away the DB-related? or maybe even incrementaly? The readonly objects are heavily referred by mutable ones (which are written in 1..n transactions per web request). So, things get simple when the mutable ones can directly reference the readonly ones (as mapped attributes.) Using a structure of non-DB (e.g. not even detached) objects would be possible but more elaborate (Well, I'm trying to find out whether the approach above bears even more complexity...) Now I need to follow my concentration that already has gone sleeping :-) Good night ... --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Many-To-One Adjacency Relation: reference set on wrong side
I've first time tried so set up a Many To One relation in one table.
After flushing, the foreign key reference is set on the wrong side,
and I failed to tell the mapper what I want.
The example has a Man table where each son has a reference to its
father:
++
class Man(object):
def __init__(self,name):
self.name = name
def __str__(self): return %s#%s'%s'%
(self.__class__.__name__,self.id,self.name)
def __repr__(self): return self.__str__()
db = create_engine('sqlite:///:memory:')
orms = create_session()
metadata = MetaData(db)
t_man = Table(man,metadata,
Column(id,Integer,primary_key=True),
Column(name,String(50)),
Column(father_id,Integer,ForeignKey(man.id)),
)
metadata.create_all()
mapper(Man, t_man, properties = {
father:relation(
Man,
uselist=False,
#remote_side=t_man.c.father_id # same error with remote_side
scalar
#remote_side=[t_man.c.father_id] # same error with remote_side
[]
)
})
# create two men:
james = Man(James)
harry = Man(Harry)
harry.father = james
orms.save(harry)
assert harry.father is james
assert james.father is None
assert harry.father_id is None
assert james.father_id is None
orms.flush()
# These both are as expected:
assert harry.father is james
assert james.father is None
# Error: son has no father id:
assert harry.father_id==harry.father.id # harry.father_id is None
# Error: father has father_id:
assert james.father_id is None # james.father_id==harry.id
# Both wrong father_ids are reflected in the database.
+++
Father attribute and father_id are inconsistent and remote_side
changes nothing.
All SA 0.4.x versions and 0.3.10,0.3.7 behave the same way. So I
consider I've misused the mapping somehow... what's wrong here ?
Thank you.
Ruben
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Many-To-One Adjacency Relation: reference set on wrong side
Thank you for pointing me to the problem (that fast !!) This was wrong indeed. It is clearified now, and working well. Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: ANN: sqlalchemy-validations 0.1
Code hardening is always good ... I like your idea. Did you already think about easy validation of a set of depending fields, too? Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.1 released
I very much appreciate the API hardening. It immediately broke tests of mine, exhibiting year-old abuse of save(). thank you ! Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] What exactly does rollback() - and which job is left for the application ?
Obviously I've used a very basic feature (rollback) without knowing exactly what it does. Even RTFM didn't clearify all. --- Problem: Using the ORM, we delete an object x. Since another object (y) is referencing x, SA clears out the ForeignKey in y pointing to x (UPDATE y SET x_id=NULL WHERE ...) But the UPDATE fails. We catch it and rollback the transaction. Any following flush() will repeat the UPDATE (and fail again forever). Obviously, rollback did not bring the Session in the state it had before the transaction. Currently, my only solution is to combine Session.rollback() with Session.clear(). The application obviously cannot lean back and enjoy the rollback() doing all the work. After clear(), the previous Session state has to be restored, resulting in a plenty of preventive save_or_update() calls. -- - Am I right that rollback() does not restore a Sessions pre- transactional state ? Is rollback() followed by Session.clear() the best solution ? Thank you, Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLalchemy coding style
What would you recommend? How are the gurus out there using sqlalchemy? I don't know what the gurus are doing. I'll answer as long as none of them does :-) It's probably what you're assuming already: Mapped classes can be treated as Active Records. Usually, I'm encapsulating these active records in their own modules. These modules can be seen as a layer directly above the relational DB, and they have all SQLAlchemy imports encapsulated. (99% in practice ;-) If you can't encapsulate, Pythons import machinery will allow us to use names like sa.Table ... so I can't see a pollution problem (at least, not worse than with any other library.) Regards- Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.4.0 Released
Just to make the thread longer, I want to say thank you - SA is a great software. I can't imagine anymore how I ever could manage projects in the Pre-SA era ;-) Regards, Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboGears: best practices for SELECTing
Can anyone answer these specific questions or point me in the direction of some further documentation? I assume that the SA doc, chapter object relational tutorial does best clearify how to create and use a session. http://www.sqlalchemy.org/docs/04/ormtutorial.html Or are there some shortcomings that experienced users cannot see anymore ? Regards, Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade-Delete causes AssertionError (Tries to blank-out primary key ...)
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 Parent/Child/Cascade issue, and now I have to rewrite it (how about re- introducing the bug ? ;-) ) Thank you very much. Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade-Delete causes AssertionError (Tries to blank-out primary key ...)
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 relationship.
The misunderstanding is obviously the question which one is the
child, which is the parent.
The ORM , as far as I understand, does never care for the table
structure. Particularly, it plays no role which table has the Foreign
Key.
Therefore, I expected the following declaration
mapper(Userdata, t_userdata, properties = {
myuser:relation(User,backref=backref(meta,cascade=delete))
})
to define a cascade where User.delete triggers a Userdata.delete.
(I expected this because the cascade keyword is in the backref,
not in the relation !)
But now it seems to me that it doesn't matter where I define the
cascade. I tested some cases and obviously the rule is the following:
The fist object that defines a property relation, becomes the
parent.
Subsequent backref, and even subsequent
addProperty(foo:relation ...) on the child play no role anymore.
It this right ? Btw, can I find this rule (who is the Parent)
somewhere in the API docs ?
Ruben
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Cascade-Delete causes AssertionError (Tries to blank-out primary key ...)
The example below raises an:
sqlalchemy.exceptions.AssertionError: Dependency rule tried to blank-
out primary key column 'userdata.user_id' on instance
'[EMAIL PROTECTED]'
The code creates 2 objects having a 1:1 relation with cascade-delete.
The ForeignKey is declared as a primary key. This seems to cause the
Error.
Versions: Python 2.4, SA 0.3.1, SA 0.3.4
class User(object):
pass
class Userdata(object):
def __init__(self, user):
self.user_id = user.id
if __name__==__main__:
db = create_engine(mysql://[EMAIL PROTECTED]/test_cascade)
session = create_session()
metadata = BoundMetaData(db)
t_user = Table(user,metadata,
Column(id,Integer,primary_key=True),
)
t_userdata = Table(userdata,metadata,
Column(user_id,Integer,ForeignKey(user.id),primary_key=True),
)
metadata.create_all()
mapper(User, t_user)
mapper(Userdata, t_userdata, properties = {
myuser:relation(User,backref=backref(meta,cascade=delete))
})
# create 1 instance of each object:
user1 = User()
session.save(user1)
session.flush()
data1 = Userdata(user1)
session.save(data1)
session.flush()
# now delete the user,
# expecting the cascade to delete userdata,too:
session.delete(user1)
session.flush() #AssertionError: Dependency rule tried to blank-
out ...
I can workaround this error by using a separate primary key in table
userdata:
t_userdata = Table(userdata,metadata,
Column(id,Integer,primary_key=True),
Column(user_id,Integer,ForeignKey(user.id)),
)
and everything works fine.
I'm wondering whether this is an SA bug, or a bad table design ?
Thanks and regards,
Ruben
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade-Delete causes AssertionError (Tries to blank-out primary key ...)
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 correction of my above code seems to be 2 lines: 1.The cascade rule changed from delete into all,delete-orphan 2.This in turn requires to maintain the relation in one of the objects: after: session.save(data1) data1.myuser = user1 # alternatively user1.meta.append(data1) will work as well I still don't understand why the ORM strictly requires all, delete- orphan here, and why delete ends up in the AssertionError. I think all stands for delete, save-update, refresh-expire, merge, expunge. But none of these rules seems to play a role is this example. (I _must_ be wrong here...) Any hint is really appreciated. Ruben --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: work directly with table clauses in transactions?
Kumar, look in this newsgroup for the subject Simple Transactions from 18.Jan.07: http://groups.google.de/group/sqlalchemy/browse_thread/thread/d1db12261e712d2f/f81e0b0370f8f17a?lnk=gstq=transactionsrnum=7#f81e0b0370f8f17a It's not your question. But maybe the discussed code is what you are looking for ? Regards, Ruben By the way, I suggest that an auto-generated doc at the SA page might be good. It could have clearified how to obtain a transaction without ORM. Of course, everybody can generate it by his own, and with his preferred tool (I used epydoc,but there are more...) Still it could come handy, e.g.by linking from the written docs into the generated. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Cascade delete-orphan: child deleted althought still referenced ?
I create a child table and a parent table. The latter holds a relation
to the child with delete-orphan cascade.
When I delete _the first_ of my 2 parents, the child is immediately
deleted, too.
***
This is my first attempt to use delete-orphan. I don't dare to report
it as a bug,
for the case I misunderstand the SA API.
The complete code:
from sqlalchemy import *
class Child(object):
def __init__(self, name):
self.childname = name
class Parent(object):
def __init__(self, name):
self.parentname = name
db = create_engine(mysql://[EMAIL PROTECTED]/test_cascade)
db.echo = True
session = create_session()
metadata = BoundMetaData(db)
t_parent = Table(parent,metadata,
Column(id,Integer,primary_key=True),
Column(parentname,String()),
Column(child_id,Integer,ForeignKey(child.id)),
mysql_engine=InnoDB,
)
t_child = Table(child,metadata,
Column(id,Integer,primary_key=True),
Column(childname,String()),
mysql_engine=InnoDB,
)
metadata.create_all()
mapper(Child, t_child)
mapper(Parent, t_parent, properties={
mychild:relation(Child,cascade=delete-orphan),
})
# create a child + 2 parents:
aChild = Child(aChild);session.save(aChild)
aParent1 = Parent(aParent1); aParent1.mychild=aChild;
session.save(aParent1)
aParent2 = Parent(aParent2); aParent2.mychild=aChild;
session.save(aParent2)
session.flush()
# it doesn't matter whether I create a new session here, or continue
with the old one
# delete first parent:
session.delete(aParent1)
# With InnoDB, the next flush raises Foreign Key constraint failure
# because aChild is deleted - while aParent2 ist still referencing it !
session.flush() #fails
# with MyISAM, I can still go ahead ...
print session.query(Child).get_by(childname=aChild) # the child is
deleted
# ... and try to delete second parent:
session.delete(aParent2) #
# next flush raises an error because aChild is not attached to session
anymore
session.flush()
It this a Bug, or did I misuse the ORM... ?
Regards
Ruben
-
Versions: sqlalchemy 0.3.3 and 0.3.1 and MySQL5.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Run initial code when object is created by the ORM
Michael, Thank you for doubling the FAQ here. I didn't expect I would miss something, that can be found via RTFM ... --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: AttributeError: 'ForeignKey' object has no attribute 'is_mutable'
Would there be any reason why someone might want to have a column type that's *not* derived from sqlalchemy.types.AbstractType? ... An exception message like Second argument to Column() should be a type, but (whatever) was found instead would probably have saved you some searching, right? Yes, indeed, it would be fine when constructing the Column failed immediately. But Column.__init__ says: This can be any subclass of types.AbstractType (...) or user-defined types. So probably Column.__init__ is not the place where the check is possible :-( and I'm not yet familiar with SA to say where it could fail most early. Ruben PS: Sorry it took much time until I could read and answer --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
