Loading ...
Sorry, an error occurred while loading the content.

Re: [metabase-dev] Re: Requirements for using metabase

Expand Messages
  • Dan Kuykendall
    ... I want to thank you for your time. I have spent a little time running thru your table upgrade code, and compared it with what one of the guys involved with
    Message 1 of 17 , Mar 6, 2001
    View Source
    • 0 Attachment
      mlemos@... wrote:
      >
      > > Do you have an example of what the array would look like?
      >
      > It is in the documentation:
      >
      > Schema description data structure
      > metabase.html#147.2.2
      >
      > Yes, you have there all you need.
      >
      > Manuel Lemos

      I want to thank you for your time. I have spent a little time running
      thru your table upgrade code, and compared it with what one of the guys
      involved with phpGW (Micheal Dean, author of DCL) wrote and I dont think
      metabase will handle our upgrade cycle as well as his program dubbed
      schema_proc.
      His code does not handle the db query issues, as we have been using the
      ones from PHPLIB for that. I do think your handling of this aspect of
      things is much nicer, but due to the amount of existing code I doubt the
      team would want to switch until we start working on phpGroupware 2.0
      The schema_proc design is strickly focues on the table creation and
      modification aspects and it will be able to handle our often troublesome
      upgrades that are involved when users skip several versions. The
      schema_proc uses a process of defing each change and then we do a quick
      discovery to see what version they are currently at and then proceed to
      loop thru all the remaining upgrade cycles that are needed.
      In metabase it appears that you must feed it the current state of the
      tables and the new state. It them figures out what needs to be done and
      does a single set of changes. This may sound better, but would be
      problematic with the large number of changes that can take place when a
      user skips several versions, and metabase would likely just decide it
      couldnt make the changes safely and stop.

      I thank you for your time yesterday in answering my questions. I wish
      you great luck with your project and will continue to push metabase into
      phpGW for its db abstraction layer abilities. As mentioned I think this
      would take time if it ever does come into being, but I do see the
      advantages to metabase.

      Also if your interested in looking at schema_proc, and the way it
      handles table changes I will send you a copy.

      Seek3r
    • mlemos@acm.org
      Hello, ... running ... guys ... think ... Really? In what aspects his code would handle schema upgrades better? ... the ... of ... the ... troublesome ...
      Message 2 of 17 , Mar 6, 2001
      View Source
      • 0 Attachment
        Hello,

        --- In metabase-dev@y..., Dan Kuykendall <dan@k...> wrote:
        > mlemos@a... wrote:
        > >
        > > > Do you have an example of what the array would look like?
        > >
        > > It is in the documentation:
        > >
        > > Schema description data structure
        > > metabase.html#147.2.2
        > >
        > > Yes, you have there all you need.
        > >
        > > Manuel Lemos
        >
        > I want to thank you for your time. I have spent a little time
        running
        > thru your table upgrade code, and compared it with what one of the
        guys
        > involved with phpGW (Micheal Dean, author of DCL) wrote and I dont
        think
        > metabase will handle our upgrade cycle as well as his program dubbed
        > schema_proc.

        Really? In what aspects his code would handle schema upgrades better?



        > His code does not handle the db query issues, as we have been using
        the
        > ones from PHPLIB for that. I do think your handling of this aspect
        of
        > things is much nicer, but due to the amount of existing code I doubt
        the
        > team would want to switch until we start working on phpGroupware 2.0
        > The schema_proc design is strickly focues on the table creation and
        > modification aspects and it will be able to handle our often
        troublesome
        > upgrades that are involved when users skip several versions. The
        > schema_proc uses a process of defing each change and then we do a
        quick
        > discovery to see what version they are currently at and then proceed
        to
        > loop thru all the remaining upgrade cycles that are needed.
        > In metabase it appears that you must feed it the current state of
        the
        > tables and the new state. It them figures out what needs to be done
        and
        > does a single set of changes. This may sound better, but would be
        > problematic with the large number of changes that can take place
        when a
        > user skips several versions, and metabase would likely just decide
        it
        > couldnt make the changes safely and stop.

        Metabase will not make the requested changes if the underlying
        database cannot perform them at all. Maybe I am not getting your point
        right, but I don't think there is a solution for this.


        >
        > I thank you for your time yesterday in answering my questions. I
        wish
        > you great luck with your project and will continue to push metabase
        into
        > phpGW for its db abstraction layer abilities. As mentioned I think
        this
        > would take time if it ever does come into being, but I do see the
        > advantages to metabase.
        >
        > Also if your interested in looking at schema_proc, and the way it
        > handles table changes I will send you a copy.

        Yes, please. Thank you.

        Manuel Lemos
      • Dan Kuykendall
        Here is what I originally got from Mike. I believe there is a small sample in there. So far it only supports mysql and pgsql. We are going to work on the other
        Message 3 of 17 , Mar 6, 2001
        View Source
        • 0 Attachment
          Here is what I originally got from Mike. I believe there is a small
          sample in there. So far it only supports mysql and pgsql. We are going
          to work on the other db servers as needed.

          Seek3r
          > > Also if your interested in looking at schema_proc, and the way it
          > > handles table changes I will send you a copy.
          >
          > Yes, please. Thank you.
          >
          > Manuel Lemos
        • mlemos@acm.org
          Hello, ... going ... This is odd. Maybe that is something that escapes my understanding, but I could not see exactly where this is better than the way Metabase
          Message 4 of 17 , Mar 6, 2001
          View Source
          • 0 Attachment
            Hello,

            --- In metabase-dev@y..., Dan Kuykendall <dan@k...> wrote:
            > Here is what I originally got from Mike. I believe there is a small
            > sample in there. So far it only supports mysql and pgsql. We are
            going
            > to work on the other db servers as needed.

            This is odd. Maybe that is something that escapes my understanding,
            but I could not see exactly where this is better than the way Metabase
            works.

            The way I see it Metabase applies all types of changes to each table
            at once. This is important because with different databases you may
            need to apply several types of changes in a different order. The way
            the schema proc works it applies all changes to a table in the same
            order. I may try to find an example where this is not the right way to
            do it.

            Another difference is that if I got it right, the schema proc
            generates scripts for all requested changes. This isn't a great
            problem. While Metabase only requires PHP, the schema proc requires a
            database client shell program.

            Other than that, it seems that the for the schema proc you have to
            write scripts to define what changes you want to make between each
            pair of supported versions.

            Metabase is way much simpler and safer. Metabase lets you make
            arbitratry version upgrades between revisions so you don't have to
            keep a batch of scripts that have to figure the right version that is
            installed and trigger the right upgrade script of changes.

            Metabase knows what is the currently installed version of the schema
            because it makes backup copies of the schema file installed for the
            last time. After parsing the currently installed and the new schema
            descriptions, it figures the differences between each of the schemas
            and applies them. So, Metabase assures you less maintenance
            nightmares. That was the main goal that made me develop the schema
            management.

            Anyway, even if you still prefer the schema proc way, that does not
            stop you to use Metabase to make the queries in a database independent
            manner. You would have less code to develop and maintain, and you
            know, the smaller your code can be, the less bugs you will have to
            fix.

            Regards,
            Manuel Lemos
          • Dan Kuykendall
            ... I guess it depends on what you want to have done ... For example, in some of the upgrades there are changes to the actual data, which we write sql
            Message 5 of 17 , Mar 7, 2001
            View Source
            • 0 Attachment
              mlemos@... wrote:
              >
              > Hello,
              >
              > --- In metabase-dev@y..., Dan Kuykendall <dan@k...> wrote:
              > > Here is what I originally got from Mike. I believe there is a small
              > > sample in there. So far it only supports mysql and pgsql. We are
              > going
              > > to work on the other db servers as needed.
              >
              > This is odd. Maybe that is something that escapes my understanding,
              > but I could not see exactly where this is better than the way Metabase
              > works.

              I guess it depends on what you want to have done

              > The way I see it Metabase applies all types of changes to each table
              > at once. This is important because with different databases you may
              > need to apply several types of changes in a different order. The way
              > the schema proc works it applies all changes to a table in the same
              > order. I may try to find an example where this is not the right way to
              > do it.

              For example, in some of the upgrades there are changes to the actual
              data, which we write sql statements for. So this allows us to change the
              table, and update the format of some of the data in the fields. If you
              were to just use your method, we would have no reliable way to make sure
              the data has been modified as nessesary.

              > Another difference is that if I got it right, the schema proc
              > generates scripts for all requested changes. This isn't a great
              > problem. While Metabase only requires PHP, the schema proc requires a
              > database client shell program.

              schema_proc does not need a database client shell prog. It should all be
              done within PHP.

              > Other than that, it seems that the for the schema proc you have to
              > write scripts to define what changes you want to make between each
              > pair of supported versions.

              Yes. I know this is overhead, but as mentioned above, it does have
              advantages to how we have had to deal with upgrade cycles of a rapidly
              changing program.

              > Metabase is way much simpler and safer. Metabase lets you make
              > arbitratry version upgrades between revisions so you don't have to
              > keep a batch of scripts that have to figure the right version that is
              > installed and trigger the right upgrade script of changes.

              Yes, this works cleaner if only the tables are being changed, but not if
              data also needs to be updated.

              > Metabase knows what is the currently installed version of the schema
              > because it makes backup copies of the schema file installed for the
              > last time. After parsing the currently installed and the new schema
              > descriptions, it figures the differences between each of the schemas
              > and applies them. So, Metabase assures you less maintenance
              > nightmares. That was the main goal that made me develop the schema
              > management.

              Im not sure there is much difference in maintance. Once nice thing about
              schema_proc is that you can step thru the upgrades for each version of
              our program and see what changed from one version to the next, and often
              we store notes as to why we changed things.

              > Anyway, even if you still prefer the schema proc way, that does not
              > stop you to use Metabase to make the queries in a database independent
              > manner. You would have less code to develop and maintain, and you
              > know, the smaller your code can be, the less bugs you will have to
              > fix.

              Yes, metabase may still get in for the query features. I may prefer to
              yank out the table management code from metabase so that the extra code
              wont slow down the program. Since PHP is an intrepreted language all the
              code, even the table create/modify functions end up being compiled, and
              its a waste of cycles for what we need.

              I do think metabase is a great product and hope it great success. But at
              this point I dont think it can handle our often insane upgrade processes
              well enough.

              --

              Seek3r (aka Dan Kuykendall)
              phpGroupWare Project Leader (http://www.phpgroupware.org)
              OGS Project Leader (http://www.ogsproject.org)
            • mlemos@acm.org
              Hello, ... table ... may ... way ... same ... way to ... the ... you ... sure ... Erm... I guess you did not realize that Metabase also manages table data
              Message 6 of 17 , Mar 7, 2001
              View Source
              • 0 Attachment
                Hello,

                > > The way I see it Metabase applies all types of changes to each
                table
                > > at once. This is important because with different databases you
                may
                > > need to apply several types of changes in a different order. The
                way
                > > the schema proc works it applies all changes to a table in the
                same
                > > order. I may try to find an example where this is not the right
                way to
                > > do it.
                >
                > For example, in some of the upgrades there are changes to the actual
                > data, which we write sql statements for. So this allows us to change
                the
                > table, and update the format of some of the data in the fields. If
                you
                > were to just use your method, we would have no reliable way to make
                sure
                > the data has been modified as nessesary.

                Erm... I guess you did not realize that Metabase also manages table
                data initialization. Keep in mind that when I designed Metabase I
                wanted it to satisfy needs that are pretty much the same as yours.



                > > Metabase knows what is the currently installed version of the
                schema
                > > because it makes backup copies of the schema file installed for
                the
                > > last time. After parsing the currently installed and the new
                schema
                > > descriptions, it figures the differences between each of the
                schemas
                > > and applies them. So, Metabase assures you less maintenance
                > > nightmares. That was the main goal that made me develop the schema
                > > management.
                >
                > Im not sure there is much difference in maintance. Once nice thing
                about
                > schema_proc is that you can step thru the upgrades for each version
                of
                > our program and see what changed from one version to the next, and
                often
                > we store notes as to why we changed things.

                CVS!? I use CVS to look at what I have changed, when and why. Schema
                definitions are always files that I put in my CVS respository for my
                projects. Browsing the CVS history and diff'ing between revisions tell
                me all I need. You do have your projects in a CVS repository, you can
                do the same without bloating your scripts with all interversion change
                procedures.

                Anyway, I am not insisting on this to make you do something that you
                don't want to do in first place. I just feel that your upgrade cycles
                would be much simpler and safer to maintain using Metabase because
                that is why developed it for my projects.

                If there is still anything that you feel that needs to be polished in
                Metabase, maybe it is something that I would like to have for the sake
                of the robustness and maintainability of my projects. So, if you still
                have crucial reasons to not use Metabase in your projects, I still
                would like to know them so I can evolve Metabase to please everybody's
                needs.

                Regards,
                Manuel Lemos
              • Dan Kuykendall
                ... OK. Let me give you a senerio and you tell me if it can do this as it is currently designed. User installs 0.1 0.2 needs the following changes: 1) Adds a
                Message 7 of 17 , Mar 7, 2001
                View Source
                • 0 Attachment
                  mlemos@... wrote:
                  >
                  > Erm... I guess you did not realize that Metabase also manages table
                  > data initialization. Keep in mind that when I designed Metabase I
                  > wanted it to satisfy needs that are pretty much the same as yours.

                  OK. Let me give you a senerio and you tell me if it can do this as it is
                  currently designed.

                  User installs 0.1

                  0.2 needs the following changes:
                  1) Adds a country field to the addressbook table
                  we also do update addressbook set country='USA'
                  2) We changed to more standard country codes for the translation system
                  and need to execute
                  update lang set lang='da' where lang='dk'

                  0.3 needs the following changes:
                  1) create accounts table
                  2) take all records from users table and move then into accounts table
                  and set teh type field to 'u' while doing so.
                  3) take all records from groups table and move then into accounts table
                  and set teh type field to 'g' while doing so.

                  0.4 needs the following changes:
                  1) create contacts table
                  2) create contacts_extra table
                  3) take records from addressbook table, and move te data into contacts
                  and contacts_extra as required

                  Now the user upgrades to 0.4, and my question is will everything take
                  place as needed if there is no running list of the changes that need to
                  take place.
                  Keep in mind that this is just an example from my head, and just a basic
                  concept of what can happen and is close to things that have actually
                  happened.
                  With schema_proc we are able to handle this easily since we can execute
                  sql statements along with the ALTER table type commands that need to be
                  done.

                  > CVS!? I use CVS to look at what I have changed, when and why. Schema
                  > definitions are always files that I put in my CVS respository for my
                  > projects. Browsing the CVS history and diff'ing between revisions tell
                  > me all I need. You do have your projects in a CVS repository, you can
                  > do the same without bloating your scripts with all interversion change
                  > procedures.

                  Yes I know it can be done with CVS, but its much easier for a user if
                  they have problems with te upgrade cycle to have all the steps right
                  their in front of them so that they can manually execute each step if
                  nessesary.

                  > Anyway, I am not insisting on this to make you do something that you
                  > don't want to do in first place. I just feel that your upgrade cycles
                  > would be much simpler and safer to maintain using Metabase because
                  > that is why developed it for my projects.

                  I am interested in metabase, which is why I keep asking the questions
                  and explaining how schema_proc handles things. If metabase can do the
                  same things, and it already supports more db's then it might be the
                  solution we need.

                  > If there is still anything that you feel that needs to be polished in
                  > Metabase, maybe it is something that I would like to have for the sake
                  > of the robustness and maintainability of my projects. So, if you still
                  > have crucial reasons to not use Metabase in your projects, I still
                  > would like to know them so I can evolve Metabase to please everybody's
                  > needs.

                  If this does show a limitation in your design, then it very well could
                  help improve metabase even further. Otherwise it will show how powerful
                  metabase actually is.

                  The one thing I would like to see is how quickly metabase alter table
                  stuff 'gives up'. Because if it gives up too easily then we should look
                  at how to improve its abilities.

                  Seek3r
                • mlemos@acm.org
                  Hello, ... table ... it is ... system ... table ... table ... contacts ... take ... to ... basic ... execute ... be ... What Metabase does is to let you define
                  Message 8 of 17 , Mar 7, 2001
                  View Source
                  • 0 Attachment
                    Hello,

                    --- In metabase-dev@y..., Dan Kuykendall <dan@k...> wrote:
                    > mlemos@a... wrote:
                    > >
                    > > Erm... I guess you did not realize that Metabase also manages
                    table
                    > > data initialization. Keep in mind that when I designed Metabase I
                    > > wanted it to satisfy needs that are pretty much the same as yours.
                    >
                    > OK. Let me give you a senerio and you tell me if it can do this as
                    it is
                    > currently designed.
                    >
                    > User installs 0.1
                    >
                    > 0.2 needs the following changes:
                    > 1) Adds a country field to the addressbook table
                    > we also do update addressbook set country='USA'
                    > 2) We changed to more standard country codes for the translation
                    system
                    > and need to execute
                    > update lang set lang='da' where lang='dk'
                    >
                    > 0.3 needs the following changes:
                    > 1) create accounts table
                    > 2) take all records from users table and move then into accounts
                    table
                    > and set teh type field to 'u' while doing so.
                    > 3) take all records from groups table and move then into accounts
                    table
                    > and set teh type field to 'g' while doing so.
                    >
                    > 0.4 needs the following changes:
                    > 1) create contacts table
                    > 2) create contacts_extra table
                    > 3) take records from addressbook table, and move te data into
                    contacts
                    > and contacts_extra as required
                    >
                    > Now the user upgrades to 0.4, and my question is will everything
                    take
                    > place as needed if there is no running list of the changes that need
                    to
                    > take place.
                    > Keep in mind that this is just an example from my head, and just a
                    basic
                    > concept of what can happen and is close to things that have actually
                    > happened.
                    > With schema_proc we are able to handle this easily since we can
                    execute
                    > sql statements along with the ALTER table type commands that need to
                    be
                    > done.

                    What Metabase does is to let you define table initial values. Although
                    it is not quite in place because I was waiting to add primary key
                    support, the idea is that you change any of those initial values,
                    Metabase manager would also be able to track and update those changes.
                    Usually those values are known constants that you use in other tables
                    like in your example. Metabase does not yet keep track of changes in
                    other tables with constant values eventually defined in base tables,
                    but it should not be a difficult thing to add and I see that is a
                    desirable features for the manager to support, so it could be added
                    some time soon.


                    >
                    > > CVS!? I use CVS to look at what I have changed, when and why.
                    Schema
                    > > definitions are always files that I put in my CVS respository for
                    my
                    > > projects. Browsing the CVS history and diff'ing between revisions
                    tell
                    > > me all I need. You do have your projects in a CVS repository, you
                    can
                    > > do the same without bloating your scripts with all interversion
                    change
                    > > procedures.
                    >
                    > Yes I know it can be done with CVS, but its much easier for a user
                    if
                    > they have problems with te upgrade cycle to have all the steps right
                    > their in front of them so that they can manually execute each step
                    if
                    > nessesary.

                    Yes, but if you distribute the different versions of the schema files,
                    the effect can be the same.



                    > > If there is still anything that you feel that needs to be polished
                    in
                    > > Metabase, maybe it is something that I would like to have for the
                    sake
                    > > of the robustness and maintainability of my projects. So, if you
                    still
                    > > have crucial reasons to not use Metabase in your projects, I still
                    > > would like to know them so I can evolve Metabase to please
                    everybody's
                    > > needs.
                    >
                    > If this does show a limitation in your design, then it very well
                    could
                    > help improve metabase even further. Otherwise it will show how
                    powerful
                    > metabase actually is.
                    >
                    >
                    > The one thing I would like to see is how quickly metabase alter
                    table
                    > stuff 'gives up'. Because if it gives up too easily then we should
                    look
                    > at how to improve its abilities.

                    That would be great. Actually I was about to finally release Metabase
                    as Open Source. As a matter of fact I am just awaiting for SourceForge
                    to approve the project. If you would like to participate, just let me
                    know and I will grant you CVS access.

                    I am not quite sure what Open Source license to use, so for now it
                    will be left in there as LGPL. When I make time to read the different
                    Open Source licences to understand which better serves for the matter,
                    I may change the license.

                    Manuel Lemos
                  • Dan Kuykendall
                    ... OK. So for now metabase would not do what we need, if I understand you correctly. This is not to say that it couldnt with a little work, but todays version
                    Message 9 of 17 , Mar 7, 2001
                    View Source
                    • 0 Attachment
                      mlemos@... wrote:
                      >
                      >
                      > What Metabase does is to let you define table initial values. Although
                      > it is not quite in place because I was waiting to add primary key
                      > support, the idea is that you change any of those initial values,
                      > Metabase manager would also be able to track and update those changes.
                      > Usually those values are known constants that you use in other tables
                      > like in your example. Metabase does not yet keep track of changes in
                      > other tables with constant values eventually defined in base tables,
                      > but it should not be a difficult thing to add and I see that is a
                      > desirable features for the manager to support, so it could be added
                      > some time soon.

                      OK. So for now metabase would not do what we need, if I understand you
                      correctly.
                      This is not to say that it couldnt with a little work, but todays
                      version wont handle the often lame things that we do with our table
                      structures.

                      > Yes, but if you distribute the different versions of the schema files,
                      > the effect can be the same.

                      Ah. Now this is an interesting idea. It basically end up being similair
                      in nature to the schema_proc design.

                      > That would be great. Actually I was about to finally release Metabase
                      > as Open Source. As a matter of fact I am just awaiting for SourceForge
                      > to approve the project. If you would like to participate, just let me
                      > know and I will grant you CVS access.

                      I will probably not be of much help with the code. I will see if Micheal
                      Dean is interested in working with you to improve metabase. He is the
                      one that wrote schema_proc, and he is simply a better programmer than I
                      am.

                      > I am not quite sure what Open Source license to use, so for now it
                      > will be left in there as LGPL. When I make time to read the different
                      > Open Source licences to understand which better serves for the matter,
                      > I may change the license.

                      IMHO I would think the LGPL would be the perfect license for you. It
                      allows code under any license to "link" to your classes, but any
                      improvements specificly to your libs must stay free. So I think the LGPL
                      would be ideal. In fact we use the LGPL for all our class files in
                      phpGroupWare.

                      --

                      Seek3r (aka Dan Kuykendall)
                      phpGroupWare Project Leader (http://www.phpgroupware.org)
                      OGS Project Leader (http://www.ogsproject.org)
                    • Manuel Lemos
                      Hello Dan, ... ok. ... Not quite. What happens with Metabase, is that when it installs a database schema, it copies the schema to a backup file. When you
                      Message 10 of 17 , Mar 11, 2001
                      View Source
                      • 0 Attachment
                        Hello Dan,

                        On 08-Mar-01 01:57:18, you wrote:

                        >> What Metabase does is to let you define table initial values. Although
                        >> it is not quite in place because I was waiting to add primary key
                        >> support, the idea is that you change any of those initial values,
                        >> Metabase manager would also be able to track and update those changes.
                        >> Usually those values are known constants that you use in other tables
                        >> like in your example. Metabase does not yet keep track of changes in
                        >> other tables with constant values eventually defined in base tables,
                        >> but it should not be a difficult thing to add and I see that is a
                        >> desirable features for the manager to support, so it could be added
                        >> some time soon.

                        >OK. So for now metabase would not do what we need, if I understand you
                        >correctly.
                        >This is not to say that it couldnt with a little work, but todays
                        >version wont handle the often lame things that we do with our table
                        >structures.

                        ok.


                        >> Yes, but if you distribute the different versions of the schema files,
                        >> the effect can be the same.

                        >Ah. Now this is an interesting idea. It basically end up being similair
                        >in nature to the schema_proc design.

                        Not quite. What happens with Metabase, is that when it installs a database
                        schema, it copies the schema to a backup file. When you want to install a
                        newer version, Metabase will always try to figure the changes by comparing
                        the new schema with the installed one that was copied to the backup file.

                        This saves up a maintenance headache, because it doesn't matter exactly
                        which version of the schema was installed because Metabase will figure the
                        changes regardless of what was the previously installed schema. There is
                        no need for extra scripts figuring the currently installed version of the
                        applications to figure what is the upgrade path.



                        >> That would be great. Actually I was about to finally release Metabase
                        >> as Open Source. As a matter of fact I am just awaiting for SourceForge
                        >> to approve the project. If you would like to participate, just let me
                        >> know and I will grant you CVS access.

                        >I will probably not be of much help with the code. I will see if Micheal
                        >Dean is interested in working with you to improve metabase. He is the
                        >one that wrote schema_proc, and he is simply a better programmer than I
                        >am.

                        ok, Metabase was approved at Sourceforge and its page there is
                        http://sourceforge.net/projects/metabase . I have yet uploaded anything
                        there because there is a part of Metabase that is built with a
                        meta-programming language that I developed but it is not yet publically
                        available. I will open its source too, hopefully soon.


                        >> I am not quite sure what Open Source license to use, so for now it
                        >> will be left in there as LGPL. When I make time to read the different
                        >> Open Source licences to understand which better serves for the matter,
                        >> I may change the license.

                        >IMHO I would think the LGPL would be the perfect license for you. It
                        >allows code under any license to "link" to your classes, but any
                        >improvements specificly to your libs must stay free. So I think the LGPL
                        >would be ideal. In fact we use the LGPL for all our class files in
                        >phpGroupWare.

                        Ok, I don't require that any improvements to my code stay free, but I
                        suppose it is ok for now. I'll leave it LGPL in there.



                        Regards,
                        Manuel Lemos

                        Web Programming Components using PHP Classes.
                        Look at: http://phpclasses.UpperDesign.com/?user=mlemos@...
                        --
                        E-mail: mlemos@...
                        URL: http://www.mlemos.e-na.net/
                        PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
                        --
                      • Dan Kuykendall
                        ... But it still leaves changes to the data out of the picture, when your dealing with situations like I used in my example. Right or wrong? ... Great, I will
                        Message 11 of 17 , Mar 11, 2001
                        View Source
                        • 0 Attachment
                          Manuel Lemos wrote:
                          >
                          > >Ah. Now this is an interesting idea. It basically end up being similair
                          > >in nature to the schema_proc design.
                          >
                          > Not quite. What happens with Metabase, is that when it installs a database
                          > schema, it copies the schema to a backup file. When you want to install a
                          > newer version, Metabase will always try to figure the changes by comparing
                          > the new schema with the installed one that was copied to the backup file.
                          >
                          > This saves up a maintenance headache, because it doesn't matter exactly
                          > which version of the schema was installed because Metabase will figure the
                          > changes regardless of what was the previously installed schema. There is
                          > no need for extra scripts figuring the currently installed version of the
                          > applications to figure what is the upgrade path.

                          But it still leaves changes to the data out of the picture, when your
                          dealing with situations like I used in my example. Right or wrong?

                          > ok, Metabase was approved at Sourceforge and its page there is
                          > http://sourceforge.net/projects/metabase . I have yet uploaded anything
                          > there because there is a part of Metabase that is built with a
                          > meta-programming language that I developed but it is not yet publically
                          > available. I will open its source too, hopefully soon.

                          Great, I will go check it out.

                          > Ok, I don't require that any improvements to my code stay free, but I
                          > suppose it is ok for now. I'll leave it LGPL in there.

                          If you dont care about improvements to your code staying free, then the
                          BSD license might be better for you

                          Seek3r
                        Your message has been successfully submitted and would be delivered to recipients shortly.