Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread User defined dyadic functions
Sun, Jun 29 2008 7:44 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

The current UDF's are monadic ie of the form FUNCTION(parameters) would it be possible to have dyadic functions ie of the form leftparam FUNCTION rightparam?


Roy Lambert
Mon, Jun 30 2008 12:08 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< The current UDF's are monadic ie of the form FUNCTION(parameters) would
it be possible to have dyadic functions ie of the form leftparam FUNCTION
rightparam? >>

Yes, it's certainly possible. Smiley Actually, at some point I do intend to
open up the data types so that you can use user-defined types and more OO
features from the SQL2003 standard (see, sometimes the standard can be good.
Wink)

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Jun 30 2008 1:34 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


>Yes, it's certainly possible. SmileyActually, at some point I do intend to
>open up the data types so that you can use user-defined types and more OO
>features from the SQL2003 standard (see, sometimes the standard can be good.
>Wink)

As always I try and research these things so I have some level of understanding and found a nice thread on UDT. It looks interesting but since I am, and intend to continue, using Delphi for development, and since I'm more f/s than c/s, with a considerable degree of reliance on tables and databound controls I'm not sure of its relevance to me. If I was moving to c/s and pure play sql it would be different.

The OO side I currently have no opinion on since that's about as much as I know Smiley Perhaps you would care to expand on it.

Roy Lambert
Mon, Jun 30 2008 3:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< The OO side I currently have no opinion on since that's about as much as
I know Smiley Perhaps you would care to expand on it. >>

Well, the simple description is that it allows you to define SQL/PSM
functions and procedures that operate within the context of a UDT, so that
you're actually defining methods of a type that act on its internal
attributes.  In the case of the OO SQL, the object class is a typed table,
and the instances of that class are the rows in the table.  Therefore, if
you had a Customer table defined as a specific type with a method called
MailingAddress, you could write something like this:

SELECT Customer.MailingAddress
FROM Customer

IOW, MailingAddress isn't a column, but rather a FUNCTION method of the
Customer type, just like with Delphi OO.  And, the MailingAddress function
has implicit access to the internal attributes (column values) of the
Customer type instances (rows).

Of course, you can do something similar now in EDB with computed columns,
but it isn't nearly as nice and complete as the OO SQL features, especially
when you get into nested types/inheritance and things like columns that are
defined as row or array types.  IOW, imagine a table type that has an
Addresses column that is an array of a type called Address that allows for
storing multiple addresses in each customer row.  You could do something
like this:

SELECT Customer.Addresses[2]
FROM customer

This is why we got rid of support for brackets around identifiers in EDB.
Smiley Array and row types are on the list for 2.0, and will be here soon.
That will serve as the basis for further inroads towards the UDT and OO
capabilities.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Jul 1 2008 2:26 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


That seems like I "should" be able to find a use for it.

Reading the threads on UDT I have a question - what level are they going to be implemented at - engine, session, database or table?

Roy Lambert
Tue, Jul 1 2008 11:32 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Reading the threads on UDT I have a question - what level are they going
to be implemented at - engine, session, database or table? >>

They would be defined at the Configuration/Engine level.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Jul 1 2008 1:16 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>They would be defined at the Configuration/Engine level.

Good, and a full suite of tools to allow them to be changed across everywhere they've been used? This was one of the major problems several people posted. They'd define something as say VARCHAR(10) and then realise it should have been / needed "upgrading" to VARCHAR(15) and it was somewhere between very difficult and impossible.

I assume also that unlike SQL Server 2005 on you're going to allow rules?

Roy Lambert
Wed, Jul 2 2008 9:45 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Good, and a full suite of tools to allow them to be changed across
everywhere they've been used? >>

Well, the idea is that when you change a base type, it is automatically
changed everywhere else or not permitted, depending upon the nature of the
change.  Of course, as I stated, this is all very preliminary so I really
don't have a lot of details to share.

<< This was one of the major problems several people posted. They'd define
something as say VARCHAR(10) and then realise it should have been / needed
"upgrading" to VARCHAR(15) and it was somewhere between very difficult and
impossible. >>

How is that difficult and/or impossible ?  Just alter the tables and change
the types, just like with any other database.

<< I assume also that unlike SQL Server 2005 on you're going to allow rules?
>>

Could you elaborate ?  I'm not sure what you mean by "rules" ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Jul 2 2008 10:55 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

Roy Lambert

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote on Wed, 2 Jul 2008 09:45:46 -0400

>Roy,
>
><< Good, and a full suite of tools to allow them to be changed across
>everywhere they've been used? >>
>
>Well, the idea is that when you change a base type, it is automatically
>changed everywhere else or not permitted, depending upon the nature of the
>change. Of course, as I stated, this is all very preliminary so I really
>don't have a lot of details to share.
>
><< This was one of the major problems several people posted. They'd define
>something as say VARCHAR(10) and then realise it should have been / needed
>"upgrading" to VARCHAR(15) and it was somewhere between very difficult and
>impossible. >>
>
>How is that difficult and/or impossible ? Just alter the tables and change
>the types, just like with any other database.

Don't ask me I'm only reporting what I read Smiley

><< I assume also that unlike SQL Server 2005 on you're going to allow rules?
> >>
>
>Could you elaborate ? I'm not sure what you mean by "rules" ?

From what I read much the same as CHECK constraints.

Naturally I can't get the same set of search results from google but this should give you an idea

CREATE TYPE USERNAME FROM VARCHAR(20)
GO
CREATE RULE USERNAME_Domain
   AS @Username = LTRIM(RTRIM(@Username))
  AND LOWER(@Username) NOT IN ('admin','administrator','guest')
GO
EXEC sp_bindrule 'USERNAME_Domain', 'USERNAME'
GO


from http://weblogs.asp.net/alex_papadimoulis/archive/2005/10/07/426930.aspx

Roy Lambert
Wed, Jul 2 2008 4:12 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< From what I read much the same as CHECK constraints. >>

Ahh, okay.  Again, a little too early to say exactly what is going to be in
there or not, but I'll certainly give everything a look during the design.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image