Cleaning generators

View: New views
13 Messages — Rating Filter:   Alert me  

Cleaning generators

by Claudio Valderrama C. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi, would someone be so kind to comment on this attached change? I was
trying to follow Ann's idea of cleaning obsolete data in generator pages,
but I wonder if I'm missing other 100 places. Seems straightforward and this
is what worries me most.
:-)

Thanks.

C.
---
Claudio Valderrama C. - www.cvalde.net
Consultant, SW developer.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

clean_gen.diff (4K) Download Attachment

Re: Cleaning generators

by Dmitry Yemanov :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Claudio,

Yes, it really looks trivial. However:

1) I really hate these conditional ODS checks. This is why I asked
whether it makes sense to continue that support, provided that we'll
have more such checks in FB3. And so far nobody objected.

2) I'd prefer to commit the low level ODS changes (at least most of
them) as a batch. Otherwise, we'll have to deal with incompatible ODS12
databases every week ;-)

So I'd defer this change for a little while.


Dmitry

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Claudio Valderrama C. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> -----Original Message-----
> From: Dmitry Yemanov [mailto:firebird2@...]
> Sent: Viernes, 06 de Noviembre de 2009 12:49
>
> Claudio,
>
> Yes, it really looks trivial. However:
>
> 1) I really hate these conditional ODS checks. This is why I asked
> whether it makes sense to continue that support, provided that we'll
> have more such checks in FB3. And so far nobody objected.

This is like running in circles. We can't now if older ODS support will be
disabled because we don't know if it's possible to integrate v2.5 as a
provider, but probably this task will be done almost at the end of the v3
development. Therefore, when do we decide if older ODS will be supported?
And at the time of the decision it will be too late to make some changes to
the run-time structures that are tied to the on-disk layout.


> 2) I'd prefer to commit the low level ODS changes (at least most of
> them) as a batch. Otherwise, we'll have to deal with
> incompatible ODS12
> databases every week ;-)

Sorry, but this is insane request from my POV.
- It requires that all developers have their ODS changes ready the same day
or weekend.
- It requires that everybody merge and post their ODS changes in a small
timeframe. Ideal for making mistakes.
- It will be a "pleasure" to contemplate all ODS changes merged to review
them instead of looking at them separately.

Is it too much problem to run the boot build phase a few times per week?

C.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Dmitry Yemanov :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Claudio Valderrama C. wrote:
>
> This is like running in circles. We can't know if older ODS support will be
> disabled because we don't know if it's possible to integrate v2.5 as a
> provider, but probably this task will be done almost at the end of the v3
> development. Therefore, when do we decide if older ODS will be supported?
> And at the time of the decision it will be too late to make some changes to
> the run-time structures that are tied to the on-disk layout.

My understanding so far was that we basically agree to drop support for
older ODS regardless of the v2.5 based provider thing. If it would be
possible, then great, otherwise nobody gonna cry either. If this is
correct, then we may consider this question closed and start the cleanup.

>> 2) I'd prefer to commit the low level ODS changes (at least most of
>> them) as a batch. Otherwise, we'll have to deal with
>> incompatible ODS12 databases every week ;-)
>
> Sorry, but this is insane request from my POV.

Your point is taken. Not sure I agree but I may follow whatever way
others feel comfortable with.

> Is it too much problem to run the boot build phase a few times per week?

I'm more worried about public testers.


Dmitry

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Paul Reeves-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Saturday 07 November 2009, Dmitry Yemanov wrote:
> > Is it too much problem to run the boot build phase a few times per
> > week?
>
> I'm more worried about public testers.
>

I think a big sign saying 'Dark Forest - Don't Go There' might be
appropriate while the ODS is undergoing changes. We can't stop public
testers but they should at least understand the risk.


Paul
--
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Claudio Valderrama C. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> -----Original Message-----
> From: Paul Reeves [mailto:preeves@...]
> Sent: Sábado, 07 de Noviembre de 2009 5:09
>
> On Saturday 07 November 2009, Dmitry Yemanov wrote:
> > > Is it too much problem to run the boot build phase a few times per
> > > week?
> >
> > I'm more worried about public testers.

Point taken, but as Paul says:

> I think a big sign saying 'Dark Forest - Don't Go There' might be
> appropriate while the ODS is undergoing changes. We can't stop public
> testers but they should at least understand the risk.

Further, we aren't even in public Alpha!
We are just starting v3.0 development since two weeks ago.
How can testers expect something stable at this time? We are in total flux!
BTW, testing at this time is for very daring people or those that love so
much the engine.

C.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Rustam Gadjimuradov :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Alex Peshkov> I'm agreed with Claudio here.
Alex Peshkov> Unstable is unstable, including ODS.

>From the past we now, that ODS may change even
between alpha-versions. :) But batch commits of ODS
changes is better than too many incompatible commits.
In any case, the earlier you will stable ODS - the better.

WBR, GR

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Dalton Calford-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

If schema's are to be implemented in version 3, then I would suggest that the RDB and MON tables are moved into their own schema.  This should be one of the primary changes implemented in the ODS.

2009/11/7 Rustam Gadjimuradov <firebird_sql@...>
Alex Peshkov> I'm agreed with Claudio here.
Alex Peshkov> Unstable is unstable, including ODS.

>From the past we now, that ODS may change even
between alpha-versions. :) But batch commits of ODS
changes is better than too many incompatible commits.
In any case, the earlier you will stable ODS - the better.

WBR, GR

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel
mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Alexander Peshkoff :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> > -----Original Message-----
> > From: Paul Reeves [mailto:preeves@...]
> > Sent: Sábado, 07 de Noviembre de 2009 5:09
> >
> > On Saturday 07 November 2009, Dmitry Yemanov wrote:
> > > > Is it too much problem to run the boot build phase a few times per
> > > > week?
> > >
> > > I'm more worried about public testers.
>
> Point taken, but as Paul says:
> > I think a big sign saying 'Dark Forest - Don't Go There' might be
> > appropriate while the ODS is undergoing changes. We can't stop public
> > testers but they should at least understand the risk.
>
> Further, we aren't even in public Alpha!
> We are just starting v3.0 development since two weeks ago.
> How can testers expect something stable at this time?

I'm agreed with Claudio here. Unstable is unstable, including ODS.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Claudio Valderrama C. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> -----Original Message-----
> From: Dalton Calford [mailto:dalton.calford@...]
> Sent: Sábado, 07 de Noviembre de 2009 14:20
>
> If schema's are to be implemented in version 3, then I would
> suggest that the RDB and MON tables are moved into their own
> schema.  This should be one of the primary changes
> implemented in the ODS.

The problem is nobody has implemented schemas beyond Ann showing which
tables should be changed.
:-)

Also, the standard wants a private schema for system tables and a public
schema for system views that output typical information.

C.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Claudio Valderrama C. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> -----Original Message-----
> From: Dmitry Yemanov [mailto:firebird2@...]
> Sent: Sábado, 07 de Noviembre de 2009 4:41
>
> My understanding so far was that we basically agree to drop
> support for
> older ODS regardless of the v2.5 based provider thing. If it would be
> possible, then great, otherwise nobody gonna cry either. If this is
> correct, then we may consider this question closed and start
> the cleanup.

Ok, let's see who is against this cleanup. I can try to do it. But I think
that for the time being (at least before the public Alpha) we are fine with
the ability to load older databases.

I will add my generators page change to my system_flag change and then I
will see if I'm allowed to commit.

C.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Adriano dos Santos Fernandes-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Claudio Valderrama C. wrote:
>
> Also, the standard wants a private schema for system tables and a public
> schema for system views that output typical information.
>
+1 for this. I think FB needs internal tables subject to changes without any notice.

The views should be the "API" and be stable for users and tools.


Adriano


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Cleaning generators

by Ann W. Harrison :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Claudio Valderrama C. wrote:

>>
>> If schema's are to be implemented in version 3, then I would
>> suggest that the RDB and MON tables are moved into their own
>> schema.  This should be one of the primary changes
>> implemented in the ODS.
>
> The problem is nobody has implemented schemas beyond Ann showing which
> tables should be changed.

Schemas would be subject to access control per the SQL standard.  Aside
from that, they just create a two-level name space.  And yes, system
specific tables should be in their own schemas.  I'd put the RDB$ tables
in one schema and the MON$ tables in another because the access rights
to the two will be different.

> Also, the standard wants a private schema for system tables and a public
> schema for system views that output typical information.
>

Switching in one release from direct system updates to private system
tables is a big step.  However, we could strongly recommend not giving
access to the system table schema generally, and further restricting
update access to that schema.  It's likely that we will need to extend
the Information Schema to handle Firebird specific features.

Regards,

Ann

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel