[Flow] TYPO3 Surf questions

[Mark Kuiphuis]

Thanks guys....

Might need to some work on this then :-) But I wouldn't be where I am 
currently at without both your help, so really appreciated :-)

So if I understand you correctly, on every deploy you are downloading 
TYPO3.Flow, TYPO3.Fluid, Libraries like Doctrine, Yaml, etc. etc.?

Cheers, Mark

P.S. Might need to work on doctrine:migrate a bit more because up until 
now we have only used doctrine:update :( Thanks for this tip....

On 29/10/2014 6:20 pm, Christian Loock wrote:
> Just to add to this:
>
> Be aware that using doctrine:update, even if it might seem very
> convient, might screw up your possibilites to generate migrations with
> doctrine:migrationgenerate. We used to use doctrine:update on our loca
> working copies aswell, untill we tried to deploy our application the
> first time to our production environment, and realized that our
> migrations were broken, since they were missing stuff. Since then, we
> made it a convention to always use doctrine:migrate and never update the
> database directly with doctrine:update. This adds a little step, but
> makes your migrations safe and tight.
>
> Also note, that composer has a cache, that will cache repositories it
> checks out, for later use. So as long as you have you composer.lock
> versioned, it should only download the repos at the first time you
> deploy, and then take them straight from the cache, which is very quick.
>
> Cheers
>
>
> Am 29.10.2014 um 09:09 schrieb Beat Guggisberg:
>> Hey Mark
>>
>> If you copied the Database with all Data in it, then it should have
>> also copied the Migrations Table. So without a codechange there should
>> not have been any migration nessessary.
>>
>> On a Development system you should have no problem just to just clear
>> your database and make a migration to come to the correct Databasae
>> structure. To test your new things that change the database you can
>> update manually with doctrine:update. Never do that on a production
>> server, because it destroys future migrations.
>>
>> To create the migrations you need on the production server, clear the
>> DB on the testserver, do a doctrine:migrate and then a
>> doctrine:migrationgenerate. Now you have a file with all the DB
>> changes in it. You can split up that file for your different packages.
>>
>> For your problem with the downloads, i have created local copies of
>> all nessessary Git repositorys. You can do that with "git clone
>> --mirror", to update them use "git remote update".
>>
>> Now you have to add them as repository in your json.
>>
>> Kind Regards
>> Beat
>>
>>
>> Am Mittwoch, 29. Oktober 2014 01:54 CET, Mark Kuiphuis
>> <mark at capesso.com.au> schrieb:
>>   Thanks Christian and Beat :-)
>>
>> Since this is all still very new to me, I wanted to test things
>> thoroughly on a local server before putting it to use on a Live
>> Production Server.
>>
>> I therefore made a copy of my development database instead of creating
>> an empty database (which I did refer to by the way in the Settings.yaml
>> in both Production and Development Contexts).
>>
>> It turned out that, because there was already a database (with tables of
>> my packages and the TYPO3.Party tables) it could not rename the
>> party_abstractparty to typo3_party_domain_model_abstractparty, because
>> that table already existed.....
>>
>> I now need to find a way to move a lot of folders from the releases
>> folder to the "shared" folder and symlink them, because I don't want to
>> download TYPO3.Flow, TYPO3.Fluid, and all libraries when I made a change
>> to one of my own packages and want to deploy these changes.
>>
>> And while my own packages have been downloaded succesfully from our own
>> git server, it did not create the necessary tables upon first run....but
>> that could maybe be due to the lack of a migration script....
>> (not something that I want to do upon each deploy anyway as it should
>> reuse existing tables and modify them instead of creating (for example
>> party_abstractparty which then should be renamed again to
>> typo3_party_domain_model_abstractparty)...
>>
>> Cheers, Mark
>>
>> On 27/10/2014 4:47 pm, Christian Loock wrote:
>>> Hey,
>>>
>>> you are probably just missing the Config for the Production Context
>>> in you
>>> base repo. Surf will automatically call everything in Production
>>> context,
>>> so you need your Configuration/Production/Settings.yaml to reflect to
>>> your
>>> actual production database.
>>>
>>> Also you are right, Surf will automatically create the whole folder
>>> structur for you. Make sure your vhost on your production node points to
>>> %projectdir%/releases/current/Web where %projectdir%= the directory you
>>> deploy to.
>>>
>>> 2014-10-27 3:37 GMT+01:00 Mark Kuiphuis <mark at capesso.com.au>:
>>>
>>>> Hi all,
>>>>
>>>> Finally found the time to start digging again in regards to TYPO3.Surf
>>>>
>>>> I am experiencing the following problem and although I do see the error
>>>> message "No datrabase selected", I have no idea how to solve it...
>>>>
>>>> staging (Vendor.Package) typo3.surf:typo3:flow:symlinkdata
>>>> staging (Vendor.Package) typo3.surf:typo3:flow:symlinkconfiguration
>>>> staging (Vendor.Package) typo3.surf:typo3:flow:copyconfiguration
>>>> Stage migrate
>>>> staging (Vendor.Package) typo3.surf:typo3:flow:migrate
>>>> Uncaught Exception
>>>> An exception occurred while executing 'SHOW FULL TABLES WHERE
>>>> Table_type
>>>> = 'BASE TABLE'':
>>>>
>>>> SQLSTATE[3D000]: Invalid catalog name: 1046 No database selected