[Rets-dev] How to calculate field sizes

Fri Mar 23 08:58:54 CDT 2007

Here is an attempt at formatting a Python line to pull metadata, for 
example:

retsdata=myrets.getmetadata({"Query":"ID=Property","SearchType":"Property","Type":"METADATA-LOOKUP_PARENT","QueryType":"DMQL","Format":"STANDARD-XML"})

When I execute this I get this back:

I know the format is incorrect but this gives you an idea of how I am 
doing this. I just need the right parts and I don't get it by looking at 
the RETS docs. Like I said, an example sheet would be great.

Thanks

And if this is better off the list, just let me know. I don't want to 
bore everyone else with my dumb questions.

Allen

JP Fielding wrote:

> dmql is the search language only, you would construct the http requests 
> for the metadata.   if im not mistaken, you will need to traverse it 
> yourself via subsequent requests as a single request fails due to an 
> invalid xml response (or at least it used to) on that server.   we pull 
> their metadata with the cart(.sf.net) rets client in incremental mode.  
> so all of those interactions are managed.
> 
> for pulling the data, it depends on what you want.   a simple example of 
> actives would be
> 
> (LocaleListingStatus=|ACTIVE-CORE)
> 
> as for the join, i havent used joining on that server, once we had to 
> implement it client-side for everyone else, we stuck with that.  i think 
> sergio (the author of that server) attached a doc describing its inner 
> workings. 
> 
> On 3/23/07, Allen Schmidt Sr. <aschmidt at fredericksburg.com 
> <mailto:aschmidt at fredericksburg.com>> wrote:
> 
>     Thanks Sergio and JP for the assistance.
> 
>     One more thing before I start digesting all you guys sent. Can you send
>     me a line of DMQL to pull metadata via RETS from MRIS? And maybe a line
>     showing a join? There needs to be a doc somewhere showing a variety of
>     common DMQL lines for retrieving data. If there is such a thing, please
>     let me know where.
> 
>     Thanks
> 
> 
>     Allen
> 
> 
> 
> 
>     Sergio Del Rio wrote:
> 
>      > Yes, you can actually do joins with the MRIS server. If you are
>      > interested in the implementation and how to execute joins on this
>      > server, please see the attached document.  It's the last thing in the
>      > document.
>      >
>      >
>      >
>      > Regards,
>      >
>      > Sergio Del Rio
>      >
>      > Templates 4 Business Inc.
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > From: rets-dev-bounces at rets.org
>     <mailto:rets-dev-bounces at rets.org> [mailto:rets-dev-bounces at rets.org
>     <mailto:rets-dev-bounces at rets.org>] On
>      > Behalf Of JP Fielding
>      > Sent: March 22, 2007 5:36 PM
>      > To: Allen Schmidt Sr
>      > Cc: Rets-dev at rets.org <mailto:Rets-dev at rets.org>
>      > Subject: Re: [Rets-dev] How to calculate field sizes
>      >
>      >
>      >
>      > the only tricky datatype should multi lookup, and that is
>     something like
>      > (max select *  max length)+(max select-1) ,  thats one slot for
>     each max
>      > size, i space for the separator for each value.  the other field
>     sizes
>      > are pretty straight forward from the metadata.   ill send you
>     (directly)
>      > an example for mysql5 innodb.   its generated directly from the
>      > metadata, so it should be pretty accurate.    in general, metadata is
>      > pretty good for most rets servers, but the problem is the occasional
>      > whack value.  for instance.... we used to use this to auto
>     generate temp
>      > tables client side for client side joining (as rets doesnt
>     provide for
>      > that server side, although mris does via extensions i believe).   we
>      > used to use this to generate tables on the fly.   the problem was,
>      > occasionally,  we'ld see something like 'TUESDAY' come back for a
>      > _datetime_ field, so we had to scap it and just store it all as
>     strings
>      > appropriately long enough for each column.  in general, mris' rets
>      > server has shadowed well when we worked with it.
>      >
>      > On 3/22/07, Allen Schmidt Sr < aschmidt at fredericksburg.com
>     <mailto:aschmidt at fredericksburg.com>
>      > <mailto:aschmidt at fredericksburg.com
>     <mailto:aschmidt at fredericksburg.com>>> wrote:
>      >
>      > General question:
>      >
>      > We pull MRIS data using a Python script. Works great for data and
>      > images. We used to use Conduit in console mode and pulled the whole
>      > file onto the filesystem and then used Python to parse it apart into
>      > MySQL tables. The table had been defined long ago and still used the
>      > old names we had like LIST_NUMB, etc.
>      > The current script pulls all the data but I only use maybe 30 of the
>      > fields for our online application.
>      >
>      > Now I would like to pull LOTS more data fields and use the
>      > system/standard names (I get them confused.)
>      >
>      > I want to define the DDL for a new table that more closely
>     matches the
>      > data I want to pull in. So I want to only define the db fields using
>      > the exact max field size. How can I do that? Is guess simple question
>      > is does anyone have a MySQL table structure for MRIS data they wanna
>      > share??
>      >
>      > Out side of that, I notice that in the metadata, for a lookup field,
>      > it only shows the field size as the lookup table ID rather than the
>      > actual largest possible size of the data in that field.
>      >
>      > I think I am rambling now. Anyone understand what I am going for?
>      >
>      > Thanks for the time.
>      >
>      > Allen
>      > _______________________________________________
>      > Rets-dev mailing list
>      > Rets-dev at rets.org <mailto:Rets-dev at rets.org> <mailto:
>     Rets-dev at rets.org <mailto:Rets-dev at rets.org>>
>      > http://lists.rets.org/mailman/listinfo/rets-dev
>      > < http://lists.rets.org/mailman/listinfo/rets-dev>
>      >
>      >
>      >
> 
> 