Metadata DDL approach

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Metadata DDL approach

Milan Babuskov-2
Hi all,

I wish to implement DDL function for all objects in the near future. I
see two approaches:

1. add a virutal getDDL method to MetadataItem
2. use visitor

While the visitor seems like a good approach, and it is tempting to use
it, I think virtual getDDL function would be a better idea in the long
run. Reasons:

- getDDL requires information about many (all?) internal properties of
the object. Visitor would have to use methods to get to those. Some
objects don't give everything away now. This means that we would
introduce some new methods just for DDL extraction - instead of having a
single getDDL method.

- virtual getDDL allows us to reuse the common things (ex. Relations =
Views and Tables and (soon) SystemTables). Also, privileges and similar
stuff that can be handled at MetadataItem level, etc. With Visitor, we
would have to duplicate some code (at least function calls if nothing else).

Therefore, if there aren't any strong arguments against it, I will
implement the virtual getDDL method.

--
Milan Babuskov
http://njam.sourceforge.net
http://www.flamerobin.org



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Metadata DDL approach

Gregory Sapunkov
Milan Babuskov:

Hello,

> I wish to implement DDL function for all objects in the near future. I
> see two approaches:
>
> 1. add a virutal getDDL method to MetadataItem
> 2. use visitor
>
> While the visitor seems like a good approach, and it is tempting to use
> it, I think virtual getDDL function would be a better idea in the long
> run. Reasons:
>
> - getDDL requires information about many (all?) internal properties of
> the object. Visitor would have to use methods to get to those. Some
> objects don't give everything away now. This means that we would
> introduce some new methods just for DDL extraction - instead of having a
> single getDDL method.

IMO, to reproduce DDL statement only public available info about the
metadata object is needed (in other words properties that define the
object should be public).

> - virtual getDDL allows us to reuse the common things (ex. Relations =
> Views and Tables and (soon) SystemTables). Also, privileges and similar
> stuff that can be handled at MetadataItem level, etc. With Visitor, we
> would have to duplicate some code (at least function calls if nothing
> else).

The main disadvantage from mine POV - encapsulating in Metadata objects
SQL code that could be specific for current version of Firebird.
Examples, to remove generator you'll write:
in Firebird 1.0
DELETE FROM RDB$GENERATOR WHERE RDB$GENERATOR_NAME = generator_name
in Firebird 1.5
DROP GENERATOR generator_name
in Firebird 2.0 (due to recommendations in Release Notes)
DROP SEQUENCE generator_name
I sure it's not the best solution to solve this question in metadata
object code.

> Therefore, if there aren't any strong arguments against it, I will
> implement the virtual getDDL method.

Therefore, I've implemented *DDLVisitor classes.

--
Gregory


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Metadata DDL approach

Milan Babuskov-2
Gregory Sapunkov wrote:
>> - virtual getDDL allows us to reuse the common things (ex. Relations =
>> Views and Tables and (soon) SystemTables). Also, privileges and
>> similar stuff that can be handled at MetadataItem level, etc. With
>> Visitor, we would have to duplicate some code (at least function calls
>> if nothing else).
>
> The main disadvantage from mine POV - encapsulating in Metadata objects
> SQL code that could be specific for current version of Firebird.
> Examples, to remove generator you'll write:

Good point. I agree that having DropVisitor is a good idea. But, DDL is
one thing, and DROP is another. I'm sure that CREATE GENERATOR, CREATE
TABLE, CREATE TRIGGER, etc. look the same in all versions? Or don't they?

--
Milan Babuskov
http://njam.sourceforge.net
http://www.flamerobin.org



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Metadata DDL approach

Gregory Sapunkov
Milan Babuskov:
> Gregory Sapunkov wrote:
>> The main disadvantage from mine POV - encapsulating in Metadata
>> objects SQL code that could be specific for current version of
>> Firebird. Examples, to remove generator you'll write:
>
> Good point. I agree that having DropVisitor is a good idea. But, DDL is
> one thing, and DROP is another. I'm sure that CREATE GENERATOR, CREATE
> TABLE, CREATE TRIGGER, etc. look the same in all versions? Or don't they?

1. IIRC, DROP is a DDL statement, too (-:
2. It's even worse to encapsulate one kind of DDL statements into object
itself and implement others (ALTER, DROP, RECREATE, ALTER or CREATE,
COMMENT...) in some different way.
3. One more example (to your question)... and again with generator
Firebird 1.x: CREATE GENERATOR generator_name
Firebird 2.0: CREATE SEQUENCE generator_name

Example with generator is not an exception. In one version you have to
DROP and CREATE an object in another you could simply RECREATE it.
Another example is current manual working with RDB$DESCRIPTION fields
and new statement COMMENT in Firebird 2.0

So I'm sure that MetadataObject and SQLProcessing are very different
entities and they should (have and must) be implemented separately.

--
Gregory


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel
Reply | Threaded
Open this post in threaded view
|

Re: Metadata DDL approach

Milan Babuskov-2
Gregory Sapunkov wrote:
>> Good point. I agree that having DropVisitor is a good idea. But, DDL
>> is one thing, and DROP is another. I'm sure that CREATE GENERATOR,
>> CREATE TABLE, CREATE TRIGGER, etc. look the same in all versions? Or
>> don't they?
>
> 1. IIRC, DROP is a DDL statement, too (-:

Well, now... :)

> 2. It's even worse to encapsulate one kind of DDL statements into object
> itself and implement others (ALTER, DROP, RECREATE, ALTER or CREATE,
> COMMENT...) in some different way.

Ok, good point.

> 3. One more example (to your question)... and again with generator
> Firebird 1.x: CREATE GENERATOR generator_name
> Firebird 2.0: CREATE SEQUENCE generator_name
>
> Example with generator is not an exception. In one version you have to
> DROP and CREATE an object in another you could simply RECREATE it.
> Another example is current manual working with RDB$DESCRIPTION fields
> and new statement COMMENT in Firebird 2.0

Thanks. I'm still not using any of advanced features, as my apps. have
to be backward compatible, so I'm mostly unaware of them.

> So I'm sure that MetadataObject and SQLProcessing are very different
> entities and they should (have and must) be implemented separately.

I'm convinced. Visitor it will be. Thanks for going into depth to
explain the reasons.

In fact, now I realize that we need CreateDDLVisitor and
RecreateDDLVisitor - one for script that generates the entire database
(isql -x), and other when user wants to change a single object
(cascading view/sp changes come to mind as well).

--
Milan Babuskov
http://njam.sourceforge.net
http://www.flamerobin.org



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Flamerobin-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel