[Rets-dev] How to calculate field sizes

Allen Schmidt Sr. aschmidt at fredericksburg.com
Fri Mar 23 10:06:55 CDT 2007


Nope. Same thing.
Are ID, SearchType, etc. correct?? Right order? What IDENTIFIER is missing?

Thanks

JP Fielding wrote:

> should your Type param be METADATA-LOOKUP instead of METADATA-LOOKUP_PARENT?
> 
> On 3/23/07, Allen Schmidt Sr. < aschmidt at fredericksburg.com 
> <mailto:aschmidt at fredericksburg.com>> wrote:
> 
>     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:
> 
>     <RETS ReplyCode="20502" ReplyText="V2.1.11 400: The IDENTIFIER was
>     empty. You must enter a valid IDENTIFIER">
>     </RETS>
> 
>     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>
>      > <mailto: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>> [mailto:
>     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>
>     <mailto: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>>
>      >      > <mailto: 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>> <mailto:
>      >     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>
>      >      >
>      >      >
>      >      >
>      >
>      >
> 
> 


More information about the Rets-dev mailing list