[Rets-dev] Behaviour when a table is asked for twice

[Libor Viktorin]

By my opinion, the server has several options:
A) It may see the second MLNumber as different from the first, in which
case it's an unknown field. Then the server may either refuse the query
and return an error, or ignore it and return less fields.
B) It may see both MLNumbers as referring to the same field, in which
case it should return just one MLNumber. In other words, it returns just
the fields mentioned in the SELECT argument, and does not return any
fields that are not there.
C) It may see the MLNumber requests as request to return two instances
of the same data. In compact format, it would return two identical
columns. In Standard-XML, I am afraid the DTD does not allow for
multiple copies of the same field, so this is not a real option and the
server should choose between A) and B).

Returning a field whose name is not in the metadata and in the DTD is
definitely wrong.

Libor
 

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Keith T. Garner
Sent: Tuesday, December 13, 2005 3:37 PM
To: rets-dev at rets.org
Subject: [Rets-dev] Behaviour when a table is asked for twice

I've run into a interesting edge case that I don't think has clearly
defined
behavior in the 1.7 spec.

A user using ezRETS managed to create a query that requested the same
field
twice.

For a quick example lets say we're doing a system-name only query that
looks
like:
   SELECT MLNumber,MLNumber FROM data:Property:ResidentialProperty
          WHERE MLNumber=1234

That translates to a RETS Query of roughly:
  QueryType=DMQL2
  SearchType=Property
  Class=ResidentialProperty
  SELECT=MLNumber,MLNumber
  QUERY=(MLNumber=1234)
  StandardNames=0

In a RDB, I would expect to get the column MLNumber twice.  However, in
the
wild, the user's HTTP log showed that an MLS vendor's RETS server return
"MLNumber" and "MLNumber1".

ezRETS ran into a problem due because MLNumber1 isn't a Table name that
exists in the RETS metadata for Property:ResidentialProperty.  I've
cleaned
stuff up to throw a clearer error than it did, but this leaves me with
some
questions.

Is the query valid in the first place?  If the query is valid, what
should a
server do?

7.4.5 (in 1.5 and 1.7) doesn't really make clear what would happen in
this
case.  It does say "[The server] MAY return fewer if some of the field
names
are invalid or if a requested field is unavailable to the user based on
security or other restrictions."  In this particular case, the server
vendor
didn't return fewer, which would be valid, but it did return something
that
wasn't asked for.  (MLNumber was asked for, not MLNumber1.)

7.6 does state that the names returned in the columns tag "are the
system-names unless standard-names were used in the query."  So, it
could be
argued that the observed behavior is out of spec as MLNumber1 does not
match
a system-name since the query included no standard-names.  Even if it
did, I
don't believe MLNumber1 is in the standard-names either.

I haven't taken this to the MLS vendor yet, as there is some question
about
the validity of the query and the open question of "what should happen."

I think in the near term, I'm going to look at a strategy of doing a
"unique" over the items for the SELECT so they are only stated once, but
this certainly doesn't seem like an invalid query on first glance.

I also could ignore any item in a result set that doesn't match up with
known RETS metadata, but that doesn't seem very correct either.
However,
its hard to tell the applications using ODBC what the native type is
when I
don't have the metadata as a guide.  I suppose I could fall back to just
treating it like text, but that doesn't seem very good either.

Thoughts, anyone?

Keith

-- 
   Keith T. Garner - Strategic Architect - Center for REALTOR(r)
Technology
     kgarner at realtors.org - 312-329-3294 - http://blog.realtors.org/crt

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev