[Rets-dev] How to calculate field sizes
JP Fielding
jp.fielding at threewide.com
Fri Mar 23 09:01:13 CDT 2007
should your Type param be METADATA-LOOKUP instead of METADATA-LOOKUP_PARENT?
On 3/23/07, Allen Schmidt Sr. <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>> 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>
> > >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070323/747e7cc1/attachment.html
More information about the Rets-dev
mailing list