Re: [Tsheetx-developers] Database Config Tables

[Scott M. <sco...@gm...>]

Hey Mark,

To quickly be able to test my upgrade script, I had to take the old install
directory structure and placed it into a directory called oldinstall off the
root context directory.  For what I've done thus far, it worked great.  So,
I think we've got the ability to allow the old upgrade/install stuff to
continue to function, we just have to direct people to have their browser
open the oldinstall/index.php page, or we could put a link in your new
install functionality too.  But, we can continue working on a new install
methodology at the same time too.  Eventually the oldinstall directory will
just disappear when the new stuff is done.

-Scott

On Mon, Feb 21, 2011 at 3:11 PM, Scott Miller <sco...@gm...>wrote:

> Oh, we'd probably want to rename the file to something other than
> version.php.  Maybe buildnumber.php?
>
> -Scott
>
>
> On Mon, Feb 21, 2011 at 3:09 PM, Scott Miller <sco...@gm...>wrote:
>
>> Actually, the first answer from that link is probably what should be
>> used.  The version.php file should be ignored (thus never checked in), but
>> the file could be generated by the developers automatically, or as they (we)
>> saw fit.  But it would have to be re-generated and included in all public
>> releases.
>>
>> -----------------------------------------------
>> Abbreviated answer pasted here:
>>
>> Wherever I need the revision I do an include: <?php include
>> 'version.php'; ?>. This "version.php" file only has the revision number.
>> Moreover it is not part of the repository (it set to be ignored). Here is
>> how I create it:
>>
>> 1) On projects where SVN is installed on the server, I also use it for
>> deployment. Getting the latest version to the server I have a script that
>> among other things does the following (it runs on the server):
>>
>> cd /var/www/project
>>
>> svn update
>> rm version.php
>> svnversion > version.php
>>
>> -----------------------------------------------
>>
>> I've always regarded cross compiling as a bit of magic; never had any
>> needs to do any of that myself.
>>
>> -Scott
>>
>>
>> On Mon, Feb 21, 2011 at 1:09 PM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>>  Ive had a look at how you can do the build number properly and it isn't
>>> particularly easy.  You start to need subversion binaries bundled in with
>>> the code or to have a makefile build process.
>>>
>>>
>>> http://stackoverflow.com/questions/111436/how-can-i-get-the-svn-revision-number-in-php
>>>
>>> I think while it would be nice to have, it will quickly become a bit of a
>>> nightmare due to ensuring compatibility with windows / nix etc.  I started a
>>> mini project to get subversion running on a
>>> commercial hosting companies servers but never got it finished as I ran
>>> out of expertise in the linux cross compiling department.  The plan was to
>>> write a script that allowed a site to update
>>> automatically through the svn checkout process.
>>>
>>> mark
>>>
>>> _____________________________________________
>>>
>>> Mob:  07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 21/02/2011 01:27, Scott Miller wrote:
>>>
>>> Well, knowing the build number is helpful in two occasions that I can
>>> come up with quickly: During development, if you're testing different
>>> versions of the same general build (trunk, or 2.0) between real "versions",
>>> you'd be able to tell the difference between the two.  And if the version
>>> numbers get messed up sometime in the future when new releases are created,
>>> we'd be able to figure out which versions were actually newer than the
>>> others a bit easier than we might otherwise be able.
>>>
>>> I'm thinking if/when we do need serialized objects, we can modify the
>>> schema at that point...
>>>
>>> -Scott
>>>
>>> On Sun, Feb 20, 2011 at 6:25 PM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>>  Scott,
>>>>
>>>> What would the benefit of having a build number actually be?  Do we have
>>>> a need for one?  The difficulty arises that you can get the version number
>>>> of an individual file and subversion will save the version number in a
>>>> predefined location in the code but this number would only be correct if
>>>> that one file was committed & changed every single time.
>>>>
>>>> I can't think of any reason to use serialised objects at the moment i
>>>> just thought there may be a use one day.  Ok leave it as tinytext, i'm sure
>>>> that'll be fine.
>>>>
>>>>
>>>> Regards
>>>> Mark Wrightson
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob:  07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>>   On 20/02/2011 20:25, Scott Miller wrote:
>>>>
>>>> I agree we don't want the svn revision number as part of the version,
>>>> but I do like having it visible.  I use fwbuilder, and it, and many other
>>>> products I can't necessarily remember at the moment, they have a version
>>>> number and a separate "build" number that is very likely an svn type
>>>> revision number; perhaps we can use something like that?
>>>>
>>>> What kinds of things can you envision being stored as serialised
>>>> objects?  Currently I'm running with a version for the new configuration
>>>> table that will use tinytext as the value field type, but this can easily be
>>>> changed at the moment...
>>>>
>>>> Thanks for the "blue print"...
>>>>
>>>> -Scott
>>>>
>>>> On Sun, Feb 20, 2011 at 12:40 PM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>>  I dont particularly think svn revision numbers are a good way of
>>>>> controlling the actual version of the application.  because a single change
>>>>> to the trunk should not constitute a requirement to run update scripts to
>>>>> modify the database etc.
>>>>>
>>>>> Maybe it should be just a text field?  it doesn't really make much
>>>>> difference though does it?  I'm thinking that in future we may end up
>>>>> storing serialised objects in the database and it may quite easily get
>>>>> larger than 255 chars.  Or should we just use tinytext?  I personally have
>>>>> no preference. 255 chars would probably be fine.
>>>>>
>>>>>
>>>>> The way the installer works is:
>>>>>
>>>>> site.class.php:
>>>>>
>>>>> 1. init config
>>>>> 2. connect to database
>>>>> If the connection to the db fails then check the config::isInstalled
>>>>> variable.
>>>>> If it is installed then show an error page, if it is not installed goto
>>>>> the page install.php?page=install
>>>>>
>>>>> Assuming the site is installed and the database connects ok
>>>>> Config::getDbConfig() is called to grab the data out of the new config
>>>>> database table.
>>>>> Inside this function it the calls runVersionCheck() which compares the
>>>>> version grabbed from the database to the value of ConfigFactory::$version
>>>>> If the versions do not match then goto the page
>>>>> install.php?page=upgrade
>>>>>
>>>>> By redirecting to install.php, the usual path of the site loading
>>>>> through index.php doesn't apply.  the install.php file loads the
>>>>> install.site.class.php instead of site.class.php
>>>>> which is slightly different.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Mark Wrightson
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob:  07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>>   On 18/02/2011 23:32, Scott Miller wrote:
>>>>>
>>>>> Mark, can you give me a brief outline of how the system figures out if
>>>>> it needs to upgrade itself?  I think I'm done with the sql stuff, but need
>>>>> to test it, and want to know what calls what.
>>>>>
>>>>> I'd start figuring it out on my own, but I need to head out for the
>>>>> weekend myself, hopefully you'll have responded by the time I get in Morning
>>>>> :-)
>>>>>
>>>>> -Scott
>>>>>
>>>>>