Re: Simple Question?

Michael Segel (mikey@segel.NO.SPAM.KINGOFMYDOMAIN.SPAM.NO.com) wrote: : Now you had mentioned. J-SPL and C-SPL. How are they part of UDO? So the SQL RDBMS engine comes with a small set of types (INTEGER, CHAR, FLOAT, DECIMAL etc) and a precisely defined set of expressions. UDO lets you add your own types and functions. For example, this is a 'C' program that takes a string literal and returns the same string literal only all upper case (one of the most popular requests here on c.d.i) #include <ctype.h> #include <stdio.h> #include <string.h> #include <stddef.h> #include <mi.h> mi_lvarchar * to_upper(intext) mi_lvarchar * intext; { mi_string * pString, * pCh; pCh = (pString = mi_lvarchar_to_string(intext)); while(*pCh) { *pCh = (char)toupper((int)*pCh); pCh++; } return mi_string_to_lvarchar(pString); } This code is compiled into a dynamically linked binary file that is stored in the filesystem in an appropriate place. Then the function is declared to UDO in the following way: CREATE FUNCTION Upper(lvarchar)RETURNS lvarchar WITH ( NOT VARIANT ) EXTERNAL NAME '$INFORMIXDIR/extend/Upper/bin/case.bld(to_upper)' LANGUAGE C; -- GRANT EXECUTE ON FUNCTION Upper(lvarchar) TO PUBLIC; Note: a) the reference to the shared library (case.bld) and the symbol within it (to_upper) b) the grant statement allowing permissions on using the function. This new function can be invoked wither through the EXECUTE FUNCTION Upper('foo'); syntax (identical to the EXECUTE PROCEDURE() except that the FUNCTION returns a value. This is moderately useful. The real power comes when you do things like this; SELECT COUNT(*) FROM Employees E WHERE Upper(E.Surname) = Upper('Segel'); The new function can be applied anywhere that an existing SQL language function can be used. Because the function is written in the 'C' language, it is very fast and can do anything that's possible in 'C' (within certain limitations: thread safe, interfactions with the OS must be carefully managed etc). The Java interface is slightly different, but the effect is the same. Code written in Java runs in the context of the server, and can be invoked through SQL. : > Let's talk Images. More precisely, let's talk images of faces. : No, I wanted to talk videos. Mike. Data is data. The algorithms are exactly the same. The reason I used 'images' is because it's easier for people to grok; we've all had to write image format code before. Fewer people get MPEG-2 or AVI formating. : A poster from the OSU math dept. Mentioned that the video : is not part of the DB. So how does the Video DB enhance : the performance over a non UDO solution? UDO is not a VCR, if that's what your getting at. The 'performance' is not the point. The flexibility of the SQL combined with the power of the object-extensibility is. UDO doesn't make the chips go any faster. It lets users (who can think clearly about the problem they are addressing) be more productive. : : [SNIP] : Go to your mainframe and ask : "Show me all the sex offenders currently not in jail : who live within the following counties." : : Now add : "Who have eyes brwn, hair brwn" : : You will get the same results. So there is a class of queries; 'Show me criminals living in [I] miles of [J] with [X] on rap sheet, with [Y] hair color, with [Z] age range'. Depending on the selectivity of [I], [J], [X], [Y], [Z] you want to do things in an entirely different order. In the general case, you provide a system that lets you ask and answer such questions with SQL, rather than a mess-o-C++. And the whole point is to let you ask these questions and have the system deal with optimization details. [ biometric snipped ] Well I can. And if you can't see the benefits of integrating things like gene-subsequencing algorithms or digitized gel comparisons into the server then I'm failing to explain what UDO is well enough.