Hi Huy, Thanks for your comments!
On 22 Apr 2009, at 05:33, huy wrote: > I guess it depends if you are going the standard SA table/mapping way > or the sqlalchemy.ext.declarative way So this is a good question to ask. As I'm just starting out with SA, I have no legacy code to update, and thus have started with the 0.5.x version where the documentation recommends using the declarative way. I don't know how this differs from the old way (besides which base class to use). What is the difference, and should I be using that? >> - I want to use reflection whenever possible. > Not sure exactly which reflection you want here but my experience with > a database of about 30+ tables, it's so much faster for development > to have a static SA table definitions file then to have it reflect on > every server reload. Of course - I want to generate static definitions in a single file, and then import that file from my python scripts. What I'm trying to avoid is when I make modifications to my db schema that I don't have to tune the class/table definitions by hand in this file. >> - I want to create a second python script that will contain one class >> definition for each in the first file. For example, let's say I >> have a >> table called "plate". The first file will contain the full definition >> for a class called "Plate_". The second file might contain: >> >> class Plate(Plate_): pass >> >> The second definition is a subclass of the first where I can put >> custom logic (if I need any) for each class. This is the class I will >> use in my scripts. I will then import this file from the many scripts >> I need to write that use this database. >> > Just wondering why you need both ? (unless you are going the > sqlalchemy.ext.declarative way.) Let's say here the "Plate" class represents the table "plate" in the database. I want to write some custom logic into the Plate class, for example a method "is_finished". This is not a field in the table, but a calculation that could depend on both data from the db and external information passed to it at runtime. The problem comes when I want to regenerate the static db definitions - my custom (non-database) definitions would be overwritten. By keeping them separate, I can regenerate the static definitions any time. I'm not sure of the meaning of your second remark about using the declarative method? How does this change things in what I'm trying to do? > If you are using the standard table/mapping, your model classes don't > have to extend explicitly an SA base class. > Also, SA can work with a simple class definition like > > class Plate(object): > pass > > and it auto injects everything itself, when you do the mapping. It's > not like java where you generate > setters and getters for every database column. That's definitely nice. The WebObjects code that was generated did create all of the setters and getters (which I see I don't need), but also defined all the relationships between the objects. I think this was the part that the latest autocode was missing. Then my subclass of that object would contain my custom logic. I'm a little unclear about that object definition above - how does this declaration talk to SA? > I think it's good to do some things manually when you first start out. > Heck, it's not really that much code. I guess you come from WO which > generated pretty much everything. Is that a bad thing? :) If a program can do it, I don't want to! My mindset is that I'd really prefer to be able to get up and running very quickly to be able to do the most common stuff, and only have to dig into the specifics when I need to optimise or do something unusual. I've been doing DBI programming in Perl for a long time, but this just thinly wrapped SQL. SA is really promising to remove the tedious SQL coding, but I think it can be made a bit easier (much like Elixir has done). Thanks again for taking to the time respond to my questions (and if you've got this far, reading through all this!). I appreciate the help. I will take a closer look at autocode to see if it can't do what I need with minimal patching. Cheers, Demitri --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
