sqlobject-discuss Mailing List for SQLObject (Page 432)
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
You can subscribe to this list here.
2003 |
Jan
|
Feb
(2) |
Mar
(43) |
Apr
(204) |
May
(208) |
Jun
(102) |
Jul
(113) |
Aug
(63) |
Sep
(88) |
Oct
(85) |
Nov
(95) |
Dec
(62) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(38) |
Feb
(93) |
Mar
(125) |
Apr
(89) |
May
(66) |
Jun
(65) |
Jul
(53) |
Aug
(65) |
Sep
(79) |
Oct
(60) |
Nov
(171) |
Dec
(176) |
2005 |
Jan
(264) |
Feb
(260) |
Mar
(145) |
Apr
(153) |
May
(192) |
Jun
(166) |
Jul
(265) |
Aug
(340) |
Sep
(300) |
Oct
(469) |
Nov
(316) |
Dec
(235) |
2006 |
Jan
(236) |
Feb
(156) |
Mar
(229) |
Apr
(221) |
May
(257) |
Jun
(161) |
Jul
(97) |
Aug
(169) |
Sep
(159) |
Oct
(400) |
Nov
(136) |
Dec
(134) |
2007 |
Jan
(152) |
Feb
(101) |
Mar
(115) |
Apr
(120) |
May
(129) |
Jun
(82) |
Jul
(118) |
Aug
(82) |
Sep
(30) |
Oct
(101) |
Nov
(137) |
Dec
(53) |
2008 |
Jan
(83) |
Feb
(139) |
Mar
(55) |
Apr
(69) |
May
(82) |
Jun
(31) |
Jul
(66) |
Aug
(30) |
Sep
(21) |
Oct
(37) |
Nov
(41) |
Dec
(65) |
2009 |
Jan
(69) |
Feb
(46) |
Mar
(22) |
Apr
(20) |
May
(39) |
Jun
(30) |
Jul
(36) |
Aug
(58) |
Sep
(38) |
Oct
(20) |
Nov
(10) |
Dec
(11) |
2010 |
Jan
(24) |
Feb
(63) |
Mar
(22) |
Apr
(72) |
May
(8) |
Jun
(13) |
Jul
(35) |
Aug
(23) |
Sep
(12) |
Oct
(26) |
Nov
(11) |
Dec
(30) |
2011 |
Jan
(15) |
Feb
(44) |
Mar
(36) |
Apr
(26) |
May
(27) |
Jun
(10) |
Jul
(28) |
Aug
(12) |
Sep
|
Oct
|
Nov
(17) |
Dec
(16) |
2012 |
Jan
(12) |
Feb
(31) |
Mar
(23) |
Apr
(14) |
May
(10) |
Jun
(26) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(6) |
2013 |
Jan
(4) |
Feb
(5) |
Mar
|
Apr
(4) |
May
(13) |
Jun
(7) |
Jul
(5) |
Aug
(15) |
Sep
(25) |
Oct
(18) |
Nov
(7) |
Dec
(3) |
2014 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
(3) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(5) |
Sep
|
Oct
(11) |
Nov
|
Dec
(62) |
2015 |
Jan
(8) |
Feb
(3) |
Mar
(15) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(19) |
2016 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(4) |
May
(3) |
Jun
(7) |
Jul
(14) |
Aug
(13) |
Sep
(6) |
Oct
(2) |
Nov
(3) |
Dec
|
2017 |
Jan
(6) |
Feb
(14) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(3) |
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
(44) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Luke O. <lu...@me...> - 2003-04-29 04:57:02
|
Nick - See my most recent reply to the list, triggered by your comment "can't subclass a class that inherits from SQLObject". I do this all the time for setting up common _connection's, so I figured I'd try it with columns, what this whole thread was about... and found that it worked! (caveats: only worked with 0.3 release, not tonight's CVS, only tested with DBMConnection, and you'll still need a real table for every concrete class you instantiate.) So I'm still not seeing what late-binding gets you (since the addX/removeX functions allow late re-definition), and anyways, we all ought to be happy subclassing works. :) Or something. Now, to track down what's wrong in CVS, and get a start on that python-based Transaction plan I started talking about... - Luke |
From: Luke O. <lu...@me...> - 2003-04-29 04:47:38
|
> 2. is there a way to control redundancy in the following example: > > class test1 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > IntCol("someOtherStuffHere")] > > class test2 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > StringCol("differentStuffThanInTest1")] > > I would like to decide only once how to represent a language in the > DBMS and use this consistently in various class definitions. > > I unsuccessfully tried to define a StringCol object, langCol, I know we're getting caught up in all sorts of things tangentially related (I'm currently in the midst of figuring out why making an abstract class with columns and then saying _columns = Super._columns + [] doesn't quite work...) But there is a somewhat simple non-SQLObject-inheritance-based way to get what you want, without the foreign table suggested by Frank. Rather than define a StringCol object, define a LangCol *class* which is a subclass of StringCol. Something like this ought to work: class LangCol(StringCol): def __init__(self, **kw): kw['length'] = 2 kw['default'] = 'en' StringCol.__init__(self, 'lang', **kw) Yep, just tested this out. Actually, just tested my example above with Super._columns, and it works too! (Using 3.0. All classes currently have a problem with CVS checked out 10 minutes ago, which was throwing me off.) So. To elaborate. You can either define your common column type as a subclass of Col (or StringCol, etc). Or you can use SQLObject inheritance with a structure like: class AbstractObject(SQLObject): _columns = StringCol('lang') class Z(AbstractObject): _columns = AbstractObject._columns + [StringCol('nother')] class Y(AbstractObject): _columns = AbstractObject._columns + [StringCol('further')] And all of this actually seems to work in SQLObject 0.3, tested using DBMConnection. Wow. What do you say to that, Nick? :) - Luke P.S. I'm still tracking down the problem with CVS, but it initially appears to be related to _SO_plainSetters and addColumn. Just a heads up, Ian. |
From: Nick <ni...@dd...> - 2003-04-29 03:46:14
|
On Mon, 2003-04-28 at 21:59, Luke Opperman wrote: > care to give a quick overview of the additional things made available > by late binding? If you're not dynamically altering the class based > on sub/super attribs, and you're mapping to a somewhat normalized set > of relations (as opposed to meta-tables of class/attributes or > similar), I don't see the difference from an inheritance perspective > at least. The main problem is the complexity you introduce with new style metaclassing using type as the super. I believe it may be possible to handle inheritance correctly, but as it is you can't really subclass a class that inherits from SQLObject. The way you defined my classes were extremely similar-- you provide the class attributes table, key, attributes, collections (_table, _idName, _columns, _joins). attributes was a dictionary rather than a list, with the keys being the attributes and the values being an Attribute object, similar to Col. I found converting code from my classes to SQLObject extremely trivial, and in some ways the resulting class definition was much simpler using SQLObject. However, my registration function only registered each class in a dictionary for reference like SQLObject does, but that's it. When you called db the DB lookup methods (which I called new() for inserts, getUnique() for unique lookups and getAggregate() to get a list of objects matching a condition), the results of the queries were stored in Value objects that track each attribute's value (and controlled type normalization, update tracking, etc.). When you tried to make a property access, __getattr__ resolved the name according to the aforementioned attributes dictionary, handling all the type checking etc. > Were there other benefits to the late-binding scheme? I'd say the one > immediate advantage to the metaclass system is that it seems much > easier to introspect on than __getattr__/__setattr__ systems I've > seen in the past. True; introspection is very limited using __getattr__ and __setattr__, but then again, what kind of introspection are you looking for here, in practical use. Sure, you won't be able to do dir(class), but all that information was available in other ways. Maybe some examples? > I suppose of immediate interest to this thread is how a late-binding > system would make implementation-inheritance like the original poster > was looking for possible. Since all the lookups are done when attributes are accessed, it's actually possible to alter the attributes dictionary (or any other class property) at any time without having to rebind properties or methods. Subclassing becomes a non-issue since we only register the name of the class to make sure it's unique. This has the advantage of being able to have class names that are identical get reside in different modules, by the way. > It still needs to map to some set of > tables, the easiest but of least interest to me for an ORM being the > meta-table system. Indeed; my model was very similar to SQLObject in many, many ways, and worked almost identically from a practical standpoint. Only the internals and method names were different. SQLObject does some things nicer, but I think that's just having better ideas for how things should be accessed than me rather than other limitations :) I'm not sure if I'm really answering your questions though. Nick |
From: Luke O. <lu...@me...> - 2003-04-29 03:13:38
|
> What is the goal behind the architecture currently in use vs. the > kind I > described? A lot of my experience in metaclassing comes from > classic > classes, so I've learned a lot from the code, but I'm wondering > what > particular advantages it has over the late binding I'm describing. > On > the surface it appears to be more limiting, but I'm ready to be > enlightened :) Hmm, I rather more deeply knowledgable about SQLObject's implementation than your own, so rather than puzzle it out myself, care to give a quick overview of the additional things made available by late binding? If you're not dynamically altering the class based on sub/super attribs, and you're mapping to a somewhat normalized set of relations (as opposed to meta-tables of class/attributes or similar), I don't see the difference from an inheritance perspective at least. But like I said, you can probably tell me faster than I can figure it out. Were there other benefits to the late-binding scheme? I'd say the one immediate advantage to the metaclass system is that it seems much easier to introspect on than __getattr__/__setattr__ systems I've seen in the past. I suppose of immediate interest to this thread is how a late-binding system would make implementation-inheritance like the original poster was looking for possible. It still needs to map to some set of tables, the easiest but of least interest to me for an ORM being the meta-table system. (the four primary ways of doing so being mentioned in the Ambler article I linked to; SQLObject takes the route of "Table for each concrete class, and all classes are concrete" :) ) - Luke |
From: Nick <ni...@dd...> - 2003-04-29 03:01:19
|
On Mon, 2003-04-28 at 17:36, Luke Opperman wrote: > Correct, the architecture is a single level of abstraction between a > relational database and python objects. It is a significantly harder > piece of work to map arbitrary inheritance trees to a relational > database, with specific tradeoffs on either the relational or > inheritance/type side of things. I don't think it's really a limitation of the model as much as the implementation. SQLObject sets up properties and functions in a very new class style, which is cool and flexible. You'll notice in the __new__ function of the metaclass how get and set properties are set up, along with assigning other attributes to lambda functions to set up the addX removeX etc. On the other hand, my implementation used __getattr__ and __setattr__ trapping to manage properties very late, at access time. This gives you the flixibility of being able to use inheritance very well, but it does slow down things a bit to have to resolve every attribute every time you access it. What is the goal behind the architecture currently in use vs. the kind I described? A lot of my experience in metaclassing comes from classic classes, so I've learned a lot from the code, but I'm wondering what particular advantages it has over the late binding I'm describing. On the surface it appears to be more limiting, but I'm ready to be enlightened :) Nick |
From: Luke O. <lu...@me...> - 2003-04-28 23:19:49
|
> On Mon, 2003-04-28 at 12:21, Bud P.Bruegger wrote: > > 1. is it possible that I have to assign __connection__ before > defining > > subclasses of SQLObject? When I don't do this, I seem to run > into > > problems. > > Yes, or define _connection in each subclass. Or define a superclass for all your sublcasses that defines _connection. > > 2. is there a way to control redundancy in the following example: ... > I had this same problem; I tried to do the same thing by making > supertest a class and test1 and test2 subclasses, but that didn't > work. > It doesn't look like the architecture allows this. Is that right? Correct, the architecture is a single level of abstraction between a relational database and python objects. It is a significantly harder piece of work to map arbitrary inheritance trees to a relational database, with specific tradeoffs on either the relational or inheritance/type side of things. http://www.agiledata.org/essays/mappingObjects.html makes many points about the challenges here, and possible implementations. Alternatively, I tend to subscribe to Chris Date's views on the merits of Relation-driven (relational calculus view of types) data design as opposed to Object-driven data design. (http://www.dbdebunk.com/). As a thin-mapper, I feel that SQLObject supports this viewpoint (but that doesn't everyone on this list does :). Back on track: I would personally recommend that the solution in the Relational world is probably Frank's Lang(SQLObject), with foreignKeys in your other classes. Inheritance for the sake of Implementation is to be particularily wary of for me, and that's what this case is. - Luke |
From: Frank B. <fb...@fo...> - 2003-04-28 21:09:05
|
Hallo, Bud P.Bruegger hat gesagt: // Bud P.Bruegger wrote: > 2. is there a way to control redundancy in the following example: > > class test1 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > IntCol("someOtherStuffHere")] > > class test2 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > StringCol("differentStuffThanInTest1")] > > I would like to decide only once how to represent a language in the > DBMS and use this consistently in various class definitions. > > I unsuccessfully tried to define a StringCol object, langCol, before > and use it in the _columns definition. This does not seem to work if > I use it in more than one class though. What about this: class Lang (SQLObject): _columns = [StringCol("lang", length=2, unique=1)] class test1 (SQLObject): _columns = [IntCol("langID", foreignKey="Lang"), IntCol("some")] class test2 (SQLObject): _columns = [IntCol("langID", foreignKey="Lang"), StringCol("different")] en = Lang.new(lang="en") t1 = test1.new(langID=en.id, some=1) t2 = test2.new(langID=en.id, different="foo") print t1.lang print t2.lang ciao -- Frank Barknecht _ ______footils.org__ |
From: Nick <ni...@dd...> - 2003-04-28 19:50:09
|
I was wondering, when instantiating a Join object, shouldn't joinColumn default to idName of the class instead of always making up the id column with the Style? I mean, if I define _idName for my class, then for every single join I have to say joinColumn = idName. Does this make sense to anyone? Why am I doing something so stupid in my database naming? Because I defined a database with the tables "user" and "group", found out pgsql didn't like those names, so I renamed the tables "users" and "groups" without chaging "user_id" and "group_id" references. Am I lazy? Yes, but I think what I'm asking makes sense on some level anyhow. Nick |
From: Nick <ni...@dd...> - 2003-04-28 18:40:05
|
On Mon, 2003-04-28 at 12:21, Bud P.Bruegger wrote: > 1. is it possible that I have to assign __connection__ before defining > subclasses of SQLObject? When I don't do this, I seem to run into > problems. Yes, or define _connection in each subclass. > 2. is there a way to control redundancy in the following example: > > class test1 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > IntCol("someOtherStuffHere")] > > class test2 (SQLObject): > _columns = [StringCol("lang", lenght=2, default='en'), > StringCol("differentStuffThanInTest1")] I had this same problem; I tried to do the same thing by making supertest a class and test1 and test2 subclasses, but that didn't work. It doesn't look like the architecture allows this. Is that right? Nick |
From: Bud P. B. <bu...@si...> - 2003-04-28 17:22:12
|
Here are two beginner questions that I hope someone can help me with: 1. is it possible that I have to assign __connection__ before defining subclasses of SQLObject? When I don't do this, I seem to run into problems. 2. is there a way to control redundancy in the following example: class test1 (SQLObject): _columns = [StringCol("lang", lenght=2, default='en'), IntCol("someOtherStuffHere")] class test2 (SQLObject): _columns = [StringCol("lang", lenght=2, default='en'), StringCol("differentStuffThanInTest1")] I would like to decide only once how to represent a language in the DBMS and use this consistently in various class definitions. I unsuccessfully tried to define a StringCol object, langCol, before and use it in the _columns definition. This does not seem to work if I use it in more than one class though. I also tried to define a function that returns an instance of StringCol, but this didn't even work once... I hope someone can point out what I'm doing wrong! Many thanks --b /----------------------------------------------------------------- | Bud P. Bruegger, Ph.D. | Sistema (www.sistema.it) | Via U. Bassi, 54 | 58100 Grosseto, Italy | +39-0564-411682 (voice and fax) \----------------------------------------------------------------- |
From: Luke O. <lu...@me...> - 2003-04-26 18:45:03
|
Yes, you're right, I did end up asking for a transaction-like concept. Hmm. The challenge remains about the same to implement this across SQLObject, but I think your metaphor/example is right on. I'm wondering whether to rely on database-implemented transactions if possible, or whether to implement it regardless across SQLObject. But now I need to think. - Luke > Your motives are well-founded, but I don't entirely agree with your > choice of metaphor. > > What you're really looking for is transactions. > > Something like: > > from Transaction import Transaction > from invoicing import Client > > t = Transaction() > c = Client(1) > t.insertObject(c) > c.address1 = "100 New Street" > c.telephone = 4045551212 > c.fax = 4045551213 > t.saveChanges() > > the you can do things like: > > from Transaction import Transaction > from invoicing import Client > > t = Transaction() > c = Client(1) > t.insertObject(c) > c.address1 = "100 New Street" > > try: > c.telephone = 40455519 > except TelephoneErr, err: > print "Error saving telephone number:", err.value > t.rollback() > else: > t.commit() > > This kind of interface would not care about whether the backend > persistence is a database, or merely simple files and would provide > the kind of atomicity you're looking for, in a more "classical" > database style. > > What do you think? > > -- > Brad Bollenbach > BBnet.ca > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > -- i find your contempt for naked feet curious. |
From: Nick <ni...@dd...> - 2003-04-26 17:49:22
|
Hi, I'm new to the project, but I've been working on a project that is so similar for the past 2 years (since Python 2.2a1) that it's fairly spooky. I mean, the classes are even named and organized almost exactly the same. However, my recent ex-employer owns the code, so this is the perfect opportunity to continue working on it. On Sat, 2003-04-26 at 11:01, Brad Bollenbach wrote: > On 04/25/03 16:56, Luke Opperman wrote: > > Hey all - > > > > Ok, I'm going to present a possibly controversial idea. I'd like to > > propose the concept of 'temporary' objects, for use in cases where > > you want to save values (say from a series of web forms) in > > SQLObject-constrained containers (columns, relationships), but don't > > want to persist to the database until the user finishes the process. > > Your motives are well-founded, but I don't entirely agree with your > choice of metaphor. > > What you're really looking for is transactions. Right on, that's what I did with my code. What I did was never run any queries and keep a pool of "dirty" object to commit when a commit() call was made, and rollback() would reset to original values. new()s and delete(s) obviously can't be done this way or it will screw up subsequent queries, so the DBIs transaction model was used in addition to the pool. It worked really well. Obviously, this would require somewhat of a change in the DBConnector class (first and foremost removing conn.commit() after each query :), but since there's a fairly complete caching mechanism it's only a matter of marking objects as dirty when modifications are made and then checking the cache and running an update() on every dirty object. Nick |
From: Brad B. <br...@bb...> - 2003-04-26 16:02:55
|
On 04/25/03 16:56, Luke Opperman wrote: > Hey all - > > Ok, I'm going to present a possibly controversial idea. I'd like to > propose the concept of 'temporary' objects, for use in cases where > you want to save values (say from a series of web forms) in > SQLObject-constrained containers (columns, relationships), but don't > want to persist to the database until the user finishes the process. > > Two use cases: 1. Creating a new temp object, modifying etc, > eventually persisting to a real SQLObject. 2. Taking an existing > SQLObject, creating a temp from it, modifying etc, and storing back > to the original record. > > Hardest part of this: dealing with foreignKeys, on persist keys have > to be updated from their fake values to the actual new objects' ids. > > Not sure whether to implement this as a helper class to SQLObject > (that takes an SQLObject on init), or directly in SQLObject. > Examples: > > > Helper class > ------------ > x = TempSQLObject.new(Person,....) #just like SQLOBject.new(....) > x.whatever > ... > y = x.persist() # y is now a real SQLObject of type Person. > > > z = Person(23) # existing object > w = TempSQLObject(z) > .... > z = w.persist() > > > Part of SQLObject > ----------------- > x = Person.temp(.....) # just like .new() > .... > x.persist() # no possibility of keeping temp object; it's real now. > > y = Person(23) > w = y.temp() > .... > y.persist(w) # or y.set(w) ? > > > Any thoughts? My immediate preference is to do it as part of > SQLObject, it would be very similar to the _SO_autoInitDone flags. > But makes a rather substantial change to the class for something that > other people may not need. The TempSQLObject direction keeps more > separation, but makes interface maintenance more difficult (in my > mind so far). Your motives are well-founded, but I don't entirely agree with your choice of metaphor. What you're really looking for is transactions. Something like: from Transaction import Transaction from invoicing import Client t = Transaction() c = Client(1) t.insertObject(c) c.address1 = "100 New Street" c.telephone = 4045551212 c.fax = 4045551213 t.saveChanges() the you can do things like: from Transaction import Transaction from invoicing import Client t = Transaction() c = Client(1) t.insertObject(c) c.address1 = "100 New Street" try: c.telephone = 40455519 except TelephoneErr, err: print "Error saving telephone number:", err.value t.rollback() else: t.commit() This kind of interface would not care about whether the backend persistence is a database, or merely simple files and would provide the kind of atomicity you're looking for, in a more "classical" database style. What do you think? -- Brad Bollenbach BBnet.ca |
From: Frank B. <fb...@fo...> - 2003-04-26 12:09:26
|
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > Ian Bicking hat gesagt: // Ian Bicking wrote: > > > I'm planning on putting 0.4 out before too long. I've added Styles and > > taken out the lazy fetching. > > Does taking out lazy fetching mean, that changed objects now will have > immediatly visible changes even under Webware? To reply to myself: changes are visible now with current cvs. Thanks a lot... ciao -- Frank Barknecht _ ______footils.org__ |
From: Brad B. <br...@bb...> - 2003-04-26 01:04:48
|
On 04/25/03 10:10, Donnal Walter wrote: > I am sure I will have other question of a more theoretical nature, > but my first question is merely to ask for recommendations for a > database backend. Since I am only exploring for now, I would am > interested in the easiest to install on my local machine. I had > planned on using Gadfly, for example, but I don't see it on the > list of databases supported by SQLObject. SQLite seems attractive, > but if I understand the instructions correctly, I would have to > compile it myself, and I don't have a C compiler. (Or is there a > Windows binary available?) What RDBMS would you recommend? Well, since you're asking for opinions, I'll offer mine: PostgreSQL. PostgreSQL is transactional, fast (enough), easy to use, featureful, and exceedingly well documented. I've recently used SQLObject and PostgreSQL to build an invoicing system, and am currently involved in a project using these same tools to build a unified credit card payment interface for multiple, pluggable, online merchant backends. PostgreSQL has a Windows binary available here: ftp://ftp3.ca.postgresql.org/pub/binary/v7.3.1/Windows/ That's the latest compiled version I found, anyway. I don't use Windows, but the PostgreSQL team is a highly-dedicated bunch and I see no reason to think the quality would suffer in a non-Linux/Unix environment. Hope that helps. -- Brad Bollenbach BBnet.ca |
From: Luke O. <lu...@me...> - 2003-04-25 22:10:43
|
Hey all - Ok, I'm going to present a possibly controversial idea. I'd like to propose the concept of 'temporary' objects, for use in cases where you want to save values (say from a series of web forms) in SQLObject-constrained containers (columns, relationships), but don't want to persist to the database until the user finishes the process. Two use cases: 1. Creating a new temp object, modifying etc, eventually persisting to a real SQLObject. 2. Taking an existing SQLObject, creating a temp from it, modifying etc, and storing back to the original record. Hardest part of this: dealing with foreignKeys, on persist keys have to be updated from their fake values to the actual new objects' ids. Not sure whether to implement this as a helper class to SQLObject (that takes an SQLObject on init), or directly in SQLObject. Examples: Helper class ------------ x = TempSQLObject.new(Person,....) #just like SQLOBject.new(....) x.whatever ... y = x.persist() # y is now a real SQLObject of type Person. z = Person(23) # existing object w = TempSQLObject(z) .... z = w.persist() Part of SQLObject ----------------- x = Person.temp(.....) # just like .new() .... x.persist() # no possibility of keeping temp object; it's real now. y = Person(23) w = y.temp() .... y.persist(w) # or y.set(w) ? Any thoughts? My immediate preference is to do it as part of SQLObject, it would be very similar to the _SO_autoInitDone flags. But makes a rather substantial change to the class for something that other people may not need. The TempSQLObject direction keeps more separation, but makes interface maintenance more difficult (in my mind so far). Enjoy, Luke |
From: Frank B. <fb...@fo...> - 2003-04-25 20:35:59
|
Hallo, Donnal Walter hat gesagt: // Donnal Walter wrote: > I am sure I will have other question of a more theoretical nature, > but my first question is merely to ask for recommendations for a > database backend. Since I am only exploring for now, I would am > interested in the easiest to install on my local machine. I had > planned on using Gadfly, for example, but I don't see it on the > list of databases supported by SQLObject. It is not currently supported, but writing support for a RDBMS in SQLite has shown to be very easy. Even I as a python beginner could do it with the initial sqlite support. But is Gadfly still in active development? I guess, SQLite will be faster anyway. > SQLite seems attractive, but if I understand the instructions > correctly, I would have to compile it myself, and I don't have a C > compiler. (Or is there a Windows binary available?) What RDBMS would > you recommend? SQLite is really cool for small or standalone applications, where you don't want to or cannot run a 'real' database server. It might be a bit more difficult to get it working in a threaded environment, but a couple of locks should make it possible as well. For bigger things I would use a db-server, though. MySQL and PostgreSQL both are good. ciao -- Frank Barknecht _ ______footils.org__ |
From: David M. C. <da...@da...> - 2003-04-25 17:56:27
|
On Fri, Apr 25, 2003 at 10:10:12AM -0700, Donnal Walter wrote: > I am sure I will have other question of a more theoretical nature, > but my first question is merely to ask for recommendations for a > database backend. Since I am only exploring for now, I would am > interested in the easiest to install on my local machine. I had > planned on using Gadfly, for example, but I don't see it on the > list of databases supported by SQLObject. SQLite seems attractive, > but if I understand the instructions correctly, I would have to > compile it myself, and I don't have a C compiler. (Or is there a > Windows binary available?) What RDBMS would you recommend? Both sqlite and pysqlite have win32 binaries. You may want to download something like dev-c++ (which comes with mingw) or cygwin in any case. http://www.bloodshed.net/dev/devcpp.html http://cygwin.com Dave Cook |
From: Donnal W. <don...@ya...> - 2003-04-25 17:10:17
|
The custom (clinical) application development framework on which I have been working consists of abstraction and presentation layers. The abstraction layer produces a directed, labeled, object graph in which the nodes support links to the presentation layer in what may be called a model-view-presenter (MVP) architecture. ("Presenters" are thick wrappers around wxPython "Views" attached to "Models" in the abstraction layer.) Until recently I had not intended to support relational database persistence for the abstraction layer, but others have convinced me that this would be a worthwhile feature to consider. Therefore, I am interested in exploring SQLObject as a possible bridge between the abstraction layer and relational databases. I am sure I will have other question of a more theoretical nature, but my first question is merely to ask for recommendations for a database backend. Since I am only exploring for now, I would am interested in the easiest to install on my local machine. I had planned on using Gadfly, for example, but I don't see it on the list of databases supported by SQLObject. SQLite seems attractive, but if I understand the instructions correctly, I would have to compile it myself, and I don't have a C compiler. (Or is there a Windows binary available?) What RDBMS would you recommend? Thanks, Donnal Walter, MD Arkansas Children's Hospital http://mindwrapper.org |
From: Peter W. <pwi...@th...> - 2003-04-25 05:02:04
|
Hi, I've been doing some work with SQLObject with debug turned on and noticed a lot more querying of the database going on than I expected. When looping over a single table like: ---- mns = MarketNote.select(MarketNote.q.id < 6) for mn in mns: print mn.id print mn.added ---- the 'print mn.added' line causes _SO_getValue to be called, 'print mn.id' doesn't cause an extra call. My understanding was that this should now not happen and the original SELECT called from iterSelect should have got all the values. Now my Python is not great so I could quite likely be doing something wrong or misunderstanding how iterators work but the debug trace (with a few more prints put in) seems to show the iterator running all the way to the end of the selected items before the prints happen which doesn't quite seem right to me. This is all against the latest CVS version. This is the debug from the code above: ---- <class 'SQLObject.SQLObject.SelectResults'> >> __iter__ SQLObject.DBConnection.SQLiteConnection >> iterSelect Select: SELECT market_notes.id, market_notes.login, market_notes.opportunity, market_notes.opportunity_desc, market_notes.added, market_notes.modified, market_notes.notes FROM market_notes WHERE (market_notes.id < 6) in while loop lazyColumns 0 in while loop lazyColumns 0 in while loop lazyColumns 0 in while loop result is None 3 _SO_getValue >> added _SO_selectOne QueryOne: SELECT added FROM market_notes WHERE id = 3 Thu Feb 27 23:38:52 2003 4 _SO_getValue >> added _SO_selectOne QueryOne: SELECT added FROM market_notes WHERE id = 4 Thu Feb 27 23:56:56 2003 5 _SO_getValue >> added _SO_selectOne QueryOne: SELECT added FROM market_notes WHERE id = 5 Fri Feb 28 00:09:59 2003 --- Am I doing something wrong here or is this a bug? Also I've been looking at adding support for an Interbase/Firebird connection, has anyone else done any work on this? regards, -- peter w. |
From: Frank B. <fb...@fo...> - 2003-04-24 16:47:50
|
Hallo, Ian Bicking hat gesagt: // Ian Bicking wrote: > I'm planning on putting 0.4 out before too long. I've added Styles and > taken out the lazy fetching. Does taking out lazy fetching mean, that changed objects now will have immediatly visible changes even under Webware? I still cannot solve my problem, where objects, that are referenced by other classes, don't have their changes visible. A simple example is an editable Tip of the Day app, where a Day can have multiple tips. The model is: class Tip(SQLObject): _columns = [ IntCol("dateID"), foreignKey='Date'), StringCol("text") ] class Date(SQLObject): _columns = [ DateTimeCol("start"), DateTimeCol("end") ] _joins = [MultipleJoin("Tip")] Now my Page has an action to change the Tip of a Day def changeT(self): req = self.request() id = req.value('id', None) text = req.value('text', None) t = Tip(id) t.text = text self._msg = '''Changed: %s ''' % t.id self.writeBody() It also has a "listTips" area, whose pseudo code looks like this: for day in Date.select("all"): prettyPrint(day) for tip in day.tips: prettyPrint(tip) Now this last printing of the tips does not reflect changes done in "changeT" until the AppServer is restarted. This is really driving me nuts... ciao -- Frank Barknecht _ ______footils.org__ |
From: David M. C. <da...@da...> - 2003-04-23 12:58:59
|
On Wed, Apr 23, 2003 at 07:36:39AM -0500, Mike Hostetler wrote: > In PostgreSQL < 7.3, 'datetime' is the same as 'timestamp'. In > PostgreSQL >= 7.3, it has been depreicated. Ah, so it does do something for a lot of people (e.g. RH 8 has PG 7.2 AFAIK), and it looks like it does the right thing in that case: class DateTimeCol(Col): # 3-03 @@: provide constraints; right now we let the database # do any parsing and checking. And DATE and TIME? def _mysqlType(self): return 'DATETIME' def _postgresType(self): return 'TIMESTAMP' Dave |
From: Mike H. <th...@bi...> - 2003-04-23 12:37:15
|
On Tue, Apr 22, 2003 at 10:11:33PM -0700, David M. Cook wrote: > There's a bogus couple of lines (544-5) in the > DBConnection.PosgresConnection.guessClass method I submitted: > > elif t.startswith('datetime'): > return Col.DateTimeCol, {} > > that were just copied from the old guessClass method. Since Postgres > doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do > anything. I haven't had a chance to look at how date handling is done, so I > don't know if changing this to something like: In PostgreSQL < 7.3, 'datetime' is the same as 'timestamp'. In PostgreSQL >= 7.3, it has been depreicated. -- mikeh |
From: David M. C. <da...@da...> - 2003-04-23 05:11:35
|
On Mon, Apr 21, 2003 at 10:16:12PM -0500, Ian Bicking wrote: > I'm planning on putting 0.4 out before too long. I've added Styles and > taken out the lazy fetching. There are a bunch of updates I want/need > to do to the documentation, but besides that I don't have any big plans > -- stuff like constraints (on the Python side) will wait. > > I might have missed something, though. Is there any unresolved issues > that should be dealt with before 0.4? There's a bogus couple of lines (544-5) in the DBConnection.PosgresConnection.guessClass method I submitted: elif t.startswith('datetime'): return Col.DateTimeCol, {} that were just copied from the old guessClass method. Since Postgres doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do anything. I haven't had a chance to look at how date handling is done, so I don't know if changing this to something like: elif t.startswith('date') or t.startswith('time'): return Col.DateTimeCol, {} is useful or not. Dave |
From: Peter W. <pw-...@te...> - 2003-04-23 04:49:56
|
On Tuesday, April 22, 2003, at 01:16 PM, Ian Bicking wrote: > I might have missed something, though. Is there any unresolved issues > that should be dealt with before 0.4? > I've been doing some more work with SQLite and come up with the following that might be useful to have. class SQLiteConnection(DBAPI): def __init__(self, dsn, autoCommit=1, **kw): assert sqlite, 'sqlite module cannot be found' self.dsn = dsn # full path to sqlite-db-file if not autoCommit and not kw.has_key('pool'): # Pooling doesn't work with transactions... kw['pool'] = 0 # use only one connection for sqlite - supports multiple cursors per connection self._conn = sqlite.connect(self.dsn) DBAPI.__init__(self, **kw) def makeConnection(self): return self._conn The autoCommit=1 and the pooling conditional is just copied directly from PostgresConnection, SQLite supports transactions so I presume that for the same reasons this is needed. I changed how it deals with getting a connection so that code like the following will work without needing to turn the results into lists, really any code where you have database access inside loops like this not just deletes. users = User.select('all') for i in users: for ul in u.userLocations: ul.destroySelf() SQLite + Python only supports one connection at a time. In my understanding the select loop should be able to run in a different connection to the delete as SQLite only locks when changing the db. I'm trying to find out exactly where the oddness is happening. Can you see any problems with doing this? -- peter w. |