|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
|
|
Cleaning generatorsHi, 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 |
|
|
Re: Cleaning generatorsClaudio,
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> -----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 generatorsClaudio 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 generatorsOn 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> -----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 generatorsAlex 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 generatorsIf 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. ------------------------------------------------------------------------------ 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> > -----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> -----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> -----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 generatorsClaudio 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 generatorsClaudio 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 |
| Free embeddable forum powered by Nabble | Forum Help |