[sqlalchemy] Re: how to handle Date values of the form YYYY-MM-00

2009-02-02 Thread rdmurray

Quoth jason kirtland j...@discorporate.us:
  Now, how do I get SQLAlchemy to pass that dictionary into the MySQLdb
  'connect'?  :)
 
 You can pass it in via the create_engine's connect_args:
 
 http://www.sqlalchemy.org/docs/05/dbengine.html#custom-dbapi-connect-arguments

Thanks.  I should have been able to find that myself :(.

--RDM


--~--~-~--~~~---~--~~
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] how to handle Date values of the form YYYY-MM-00

2009-02-01 Thread rdmurray

I have an existing MySQL database (that I do not control) with schema
fields defined using the 'Date' type.  The values that occur in these
fields often have a 'day' of '00', and sometimes a month of '00', and
sometimes the field's value is -00-00.  The zeros are used to indicate
don't know (or, sometimes, don't care).

Since '00' is invalid for the fields in a Python DateTime, it seems as though
I can't actually use DateTime to manage these values.  My application
should be able to use them as strings, but how do I arrange to do that?
The conversion to DateTime is presumably taking place at the DBAPI level.

--RDM


--~--~-~--~~~---~--~~
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: how to handle Date values of the form YYYY-MM-00

2009-02-01 Thread rdmurray

Quoth Michael Bayer mike...@zzzcomputing.com:
 
 Assuming these columns are ultimately CHAR or VARCHAR on the mysql  
 side, build your own Date type using TypeDecorator in conjunction with  
 the String type.  MySQLdb's date/time functionality only takes effect  
 for columns that are of the DATE, TIME or DATETIME columns.

No, as I said, these are DATE files on the MySQL side.  Which
is exactly the problem.  If they were CHAR, I wouldn't have
a problem :)

 On Feb 1, 2009, at 2:58 PM, rdmur...@bitdance.com wrote:
 
 
  I have an existing MySQL database (that I do not control)
  with schema fields defined using the 'Date' type.  The values
  that occur in these fields often have a 'day' of '00', and
  sometimes a month of '00', and sometimes the field's value is
  -00-00.  The zeros are used to  indicate don't know
  (or, sometimes, don't care).
 
  Since '00' is invalid for the fields in a Python DateTime, it
  seems  as though I can't actually use DateTime to manage
  these values.  My application should be able to use them as
  strings, but how do I arrange to do  that?  The conversion to
  DateTime is presumably taking place at the DBAPI  level.
 
  --RDM


--~--~-~--~~~---~--~~
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: how to handle Date values of the form YYYY-MM-00

2009-02-01 Thread rdmurray

Quoth jason kirtland j...@discorporate.us:
 
 rdmur...@bitdance.com wrote:
  I have an existing MySQL database (that I do not control) with schema
  fields defined using the 'Date' type.  The values that occur in these
  fields often have a 'day' of '00', and sometimes a month of '00', and
  sometimes the field's value is -00-00.  The zeros are used to indicate
  don't know (or, sometimes, don't care).
  
  Since '00' is invalid for the fields in a Python DateTime, it seems as 
  though
  I can't actually use DateTime to manage these values.  My application
  should be able to use them as strings, but how do I arrange to do that?
  The conversion to DateTime is presumably taking place at the DBAPI level.
 
 Check out the MySQLdb docs for the 'conv' type mapping option to 
 connect(). I think you should be able to override the default datetime 
 with your own convert that falls back to a string or whatever you'd like 
 it to do.

That sounds promising, and I doubt I would have found that just by googling,
so thanks!

Now, how do I get SQLAlchemy to pass that dictionary into the MySQLdb
'connect'?  :)

--David



--~--~-~--~~~---~--~~
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: inferring object class/table directly

2008-12-03 Thread rdmurray

On Tue, 2 Dec 2008 at 23:21, Faheem Mitha wrote:
 Yes, I was looking for this, and printed out obj.__dict__ but didn't
 see it there. A dictionary of attributes is very useful in theory, but
 doesn't always seem to have all attributes. Is this documented
 anywhere?

Try dir(obj).  You'll see it there.  The __dict__ is only for instance
attributes.

 Not too difficult.  You can also use type(obj) instead of
 obj.__class__.

 I thought of trying this, but didn't. It didn't seem likely to work,
 anyway. Is either of these preferred over the other in terms of API
 stability, and if so, why?

obj.__class__ is a python thing, as is type(obj), and neither of
those is changing in python 3.0, so I'd think both would be stable API
wise :)  However, the documentation of __class__ makes it clear you
get the class back, while the documentation of the 'type' built in
function does not...so I'd lean toward using __class__, myself.  It
also means you'll get an earlier error if you accidentally pass
something that is not actually a class instance into your function.

--RDM

--~--~-~--~~~---~--~~
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] extending pre-existing tables

2008-11-10 Thread rdmurray

I sent this last week but it seems like it may not have been
posted to the list...at least, I haven't seen any responses :)

-- Forwarded message --
Date: Tue, 4 Nov 2008 18:00:57 -0500 (EST)
From: [EMAIL PROTECTED]
To: sqlalchemy@googlegroups.com
Subject: extending pre-existing (read only) tables

I've got a somewhat oddball situation, and I'm hoping for some pointers
to the right sqlalchemy features to handle this.  Or, failing that,
hints as to the places I'm going to need to write code to compensate
for the weirdness I have to deal with.

The situation is that I get periodic copies of a set of database tables.
In my local database, I need to provide supplemental data that is
maintained only in my copy.

In my application library, I need to support two models: a model that
includes only the data of which I get periodic copies, and a second
model that includes my supplemental data.  So, object wise what I think
I want to have is a set of objects for the imported data, and then
a second set of objects that subclasses the first and extends them.
(ex: a Publication object, and then an ExtendedPublication object).
So I have two sets of tables, the base tables (whose schema I would
prefer not to touch), and a second set of parallel tables containing
my local data.  On import, I just drop and replace the base tables,
leaving my tables untouched.

Right now I'm playing with mapper inheritance.  The first stumbling
block I've come to is the case where the local table doesn't yet have
a row for the object from the base table.  In that case, a query on my
subclassed object returns nothing.  Do I need to write an import program
that creates rows in the local tables for any items in the imported data
that don't yet have them?  That strikes me as rather fragile.  Is there
a way to automate the creation of the local table row with default values?

Or am I approaching this all wrong?

--RDM

--~--~-~--~~~---~--~~
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: extending pre-existing tables

2008-11-10 Thread rdmurray

On Mon, 10 Nov 2008 at 17:19, Michael Bayer wrote:
 Possibly.  The fragility here is that you are relying on a model
 that isn't actually implemented here, i.e. that your application is
 written around a table inheritance assumption when that is not
 actually the case - the extended tables may or may not have a row
 present for a corresponding base row.   It would likely be more
 straightforward to implement a non-inheriting system.

OK.  Is there a way to do that and still have the (for example)
ExtendedPublication object inherit from the Publication object, or do
I need to switch to an object composition scheme?  In which case
pre-populating the extended tables may be a lot easier :)

--RDM

--~--~-~--~~~---~--~~
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] extending pre-existing (read only) tables

2008-11-04 Thread rdmurray

I've got a somewhat oddball situation, and I'm hoping for some pointers
to the right sqlalchemy features to handle this.  Or, failing that,
hints as to the places I'm going to need to write code to compensate
for the weirdness I have to deal with.

The situation is that I get periodic copies of a set of database tables.
In my local database, I need to provide supplemental data that is
maintained only in my copy.

In my application library, I need to support two models: a model that
includes only the data of which I get periodic copies, and a second
model that includes my supplemental data.  So, object wise what I think
I want to have is a set of objects for the imported data, and then
a second set of objects that subclasses the first and extends them.
(ex: a Publication object, and then an ExtendedPublication object).
So I have two sets of tables, the base tables (whose schema I would
prefer not to touch), and a second set of parallel tables containing
my local data.  On import, I just drop and replace the base tables,
leaving my tables untouched.

Right now I'm playing with mapper inheritance.  The first stumbling
block I've come to is the case where the local table doesn't yet have
a row for the object from the base table.  In that case, a query on my
subclassed object returns nothing.  Do I need to write an import program
that creates rows in the local tables for any items in the imported data
that don't yet have them?  That strikes me as rather fragile.  Is there
a way to automate the creation of the local table row with default values?

Or am I approaching this all wrong?

--RDM

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---