I tried autocode but I found it limiting due to the use of SA's
MetaData collection as the model. An alternative approach has worked
quite well: persist the results introspection queries to a set of
physical tables and wrap those (metadata) tables with SA. The code-
generation is now a standard 'pushing objects through templates
problem' (for which I use Cheetah). I use the cog tool to allow me to
mix auto-generated code in the same file as hand-maintained stuff (for
example, I find it difficult to auto-generate relations with
appropriate names and uselist so prefer to manually name them with
correct pluralization and so on)
pjjH
#[[[cog
# import cog
# from chimera import Mongo
# m = Mongo(dataserver='BANANA', database='fruit')
#]]]
#[[[end]]]
#[[[cog
# cog.outl("%s" % m.emit_sql_alchemy_tables())
#]]]
#[[[end]]]
#[[[cog
# cog.out("%s" % m.emit_sql_alchemy_mappers())
#]]]
#[[[end]]]
# This is hand-maintained code
class_mapper(Foo).add_properties({'Fruits' : relation(Fruit)})
On Apr 22, 3:04 pm, thatsanicehatyouh...@mac.com wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
