Re: [Babeldoc-devel] A few more questions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I guess first problem could be easily solved by adding clearCache method.
After config table updating, this method should be called to empty cache.
Next time an component needs a config db should be queried and get all data
again.

Dejan

----- Original Message -----
From: <ek...@ba...>
To: "bruce" <br...@mc...>
Cc: "Babeldoc Developers List" <bab...@li...>
Sent: Thursday, March 27, 2003 4:14 PM
Subject: Re: [Babeldoc-devel] A few more questions

>
> Hmmmm ... interesting.  I was planning on building an administrator UI
> that would be used to update the CONFIG table.  My hope (and my
> manager's demand) was that new and modified pipelines could be added to
> the system by an administrator while the system was running.  This means
> that we will need to possibly modify a pipeline online while the system
> is running without a restart.  Additionally, we will need to add new
> pipelines without a system restart.
>
> It appears that there may be two problems with this.
> 1. The system caches the database information and does not go back to
> the DB each time it needs it (for efficiency I'm sure).  Any chance of
> there being a "switch"/"configuration parameter" to turn this feature
> off?
>
> 2. My DBA will demand that I not append two fields together into one
> (config_nm).  Additionally, it will be simpler for my UI to have this
> field (pipeline name/id) broken out.
>
> Am I proposing something here that is going to cause me a lot of grief
> to implement?  Am I "stirring things up" here that I am going to regret
> later?
>
> Erik
>
>
>
>
>
> bruce <br...@mc...>@lists.sourceforge.net on 03/27/2003
> 10:01:53 AM
>
> Sent by:    bab...@li...
>
>
> To:    "Babeldoc Developers List" <bab...@li...>
> cc:
> Subject:    Re: [Babeldoc-devel] A few more questions
>
>
> On Thursday 27 March 2003 09:55 am, ek...@ba... wrote:
> > Thanks again for your help.  I have quickly reviewed your comments
> > below.  I *may* need to make a modification to the CONFIG table to
> break
> > out the Pipeline Name from the Config Name field to pacify my DBA.
> > Hopefully it won't be a lot of additional coding on my part.  Thanks
> > again Bruce.
>
> No problem.   There is no real need for breaking this out - its not like
> the
> configuration table is going to be a high-volume operation - in fact its
> read
> only too.  Additionally this table is never re-read (well the same rows
> are
> never re-read) - the configuration information is cached.
>
> > Erik
>
> > bruce <br...@mc...> on 03/27/2003 09:37:44 AM
> >
> > To:    ek...@ba..., bab...@li...
> > cc:
> > Subject:    Re: [Babeldoc-devel] A few more questions
> >
> >
> > OK,
> >
> > Erik here are the answers to your questions.  There is a command that
> > might
> > interest you:  sqlload:
> >
> > build\bin\babeldoc sqlload
> >
> > This loads configuration files into a database.
> >
> > Here goes....
> >
> > On Wednesday 26 March 2003 11:13 am, ek...@ba... wrote:
> > > ... though CERTAINLY not the end of my questions ... most of these
> > > questions are based off of reading all the properties files inside
> of
> > > babeldoc_core.jar, as this is my "starting point" ... so bear with
> me.
> > >
> > > -- What is the "<pipeline>.type" if I want to get my configuration
> > > information via JDBC (i.e. Not simple or xml, right?)
> >
> > Correct - The type here is how do you define the pipeline - in the
> case
> > where
> > you want to store the pipeline configuration in the database, you will
> > want
> > to choose "simple".  This means that the PipelineStageFactory will go
> to
> > the
> > configuration service to get the pipeline configuration.  Remember
> that
> > you
> > will be providing a SQL configuration service so all is well here.
> >
> > > -- What is the function of "compile=yes|no" in
> > > pipeline/compiler.properties?
> >
> > This is do caching of the pipelinestages and preloading.  It is
> possible
> > to
> > take this a lot futher and use something like BCEL and actually at
> > runtime
> > "glue" all of the pipelinestages together that form a pipeline using
> > ByteCodes.  This is not implemented.
> >
> > > -- If I want to use database journaling for Sybase, I realize that I
> > > will need to create a new class (most likely named
> > > com.babeldoc.sql.journal.SybaseJournal) and make an entry for it in
> >
> > the
> >
> > > journal/config.properties file, right?  Additionally, I will need to
> > > create the file journal/sybase/config.properties.  My question is
> what
> > > properties do I use in this file and what are the valid values?  Is
> it
> > > just "resourceName=babel-journal"?
> >
> > Correct and correct.  You will (most likely) need to write a class
> > SybaseJournal which extends GenericJournal (which does most of the
> > work).
> > Now, however you set that up, all the sql code in babeldoc does not
> > manage
> > the JDBC connections directly.  They use a resource metaphor - you
> will
> > need
> > to get a named resource (babel-journal) and then check-in and
> check-out
> > connections for your use.
> >
> > Now, you *DON'T* need to create a file
> journal/sybase/config.properties
> > unless
> > there are parameters that you need to store in that file that are
> > specifically necessary to configure your SybaseJournal (which I
> > seriously
> > doubt).  The configuration file journal/sql/config.properties informs
> > the
> > GenericSqlJournal the name of the resource to use to connect to the
> > journal
> > database - you dont even need to override this setting.  What you *DO*
> > need
> > to override is the resource setting for babel-journal.  This is done
> in
> > resource/babel-journal configuration.  Take a look at the one in the
> sql
> > module.
> >
> > > -- It appears that pipeline/config.properties contains entries for
> >
> > each
> >
> > > pipeline that is available.  If I am using JDBC to store my pipeline
> > > configuration information, do I still need this file?  Is there a
> way
> >
> > to
> >
> > > represent this in the database?
> >
> > No, every property file in the config directory gets placed into the
> > database.
> >
> > > -- I've noticed that the Primary Key for the CONFIG table is
> cfg_name,
> > > which I believe represents a single "line" in a pipeline's
> > > configuration, right?  If that is so, how do we distinguish between
> > > configuration "lines" for different pipelines?  Should pipeline_id
> (or
> > > something like this) also be part of the primary key for the CONFIG
> > > table?
> >
> > No, the CONFIG table stores the file and line number information in a
> > single
> > column - take a look at the SqlConfigService code.  This simply pastes
> > the
> > config "file" and the property name together (separated by a period)
> and
> > places in the first column.  This makes life simple - no joins.
> >
> > > -- Do entries need to be made in service/query.properties for
> Journal
> > > and PipelineStageFactory in order to support JDBC?  It appears that
> > > there are already entries in there for "simple" and "xml".
> >
> > No, see above
> >
> > > -- From the "Source" and "Binary" installations that I did from
> > > Babeldoc, I do not see directories for "config" files except for
> > > multiple instances in the "src" subdirectories under each major
> > > component (such as "core", "sql", etc.).  In a production /
> deployment
> > > environment, what is the structure for the directory(ies) in which
> the
> > > config files go?
> >
> > Let me investigate this.
> >
> > > I'm sorry if some of these questions seem ignorant ... I'm trying
> very
> > > hard to get up-to-speed as quickly as possible as I have tight
> >
> > deadlines
> >
> > > to meet.
> > >
> > > Erik
> > > The information in this e-mail, and any attachment therein, is
> > > confidential and for use by the addressee only. If you are not the
> > > intended recipient, please return the e-mail to the sender and
> delete
> >
> > it
> >
> > > from your computer. Although The Bank of New York attempts to sweep
> > > e-mail and attachments for viruses, it does not guarantee that
> either
> > > are virus-free and accepts no liability for any damage sustained as
> a
> > > result of viruses.
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel