[Rets-dev] How to calculate field sizes
JP Fielding
jp.fielding at threewide.com
Fri Mar 23 10:16:08 CDT 2007
if i remember python (its been a while), the dictionary you're passing in
looks like the first value is mapping the key "Query" to the value
"ID=Property". i assume this is just a typo? and that would explain why
your identifier is missing, because you havent sent an ID param, just a
Query param.
On 3/23/07, Allen Schmidt Sr. <aschmidt at fredericksburg.com> wrote:
>
> 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>
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070323/7869a4d9/attachment.html
More information about the Rets-dev
mailing list