[Flow] TYPO3 Surf questions

[Christian Loock]

Hey,

so yes, using migrations is really a must have when you want to deploy 
with surf. For me it sounds like, you didnt create your database that 
you run your deployment onto, with migrations in the first place. Thats 
probably why you run into the problem that tables are trying to be 
created, that allready exist. The status of executed migrations is 
stored inside a database table called somewhat like 'migrationstatus' or 
so. (Not sure at the moment). You could try creating an empty database, 
then run all migrations that come with flow and after that creating your 
own migrations with doctrine:migrationgenerate. Now run your migrations. 
After that you should be able to copy the migrationstatus table from 
this new database into your old database. Migrations "should" now run fine.

Surf installs a fresh new installation of your project, every time you 
deploy with it. This way, you are able to roll back your releases as you 
desire, in case something in your latest release doesnt work as intened. 
Migrations play a important role in that too, since they are necessary 
to safely rollback your database structure aswell. That's why I wouldnt 
recommend to put packages in the shared folder. We deploy our flow 
application, basically using the default workflow that comes with surf, 
with only minor additions. It doesnt really take that long to deploy 
with it, so I dont really see any value in modifying the deployment that 
heavily, since you dont really gain that much.

Cheers,

Christian


Am 29.10.2014 um 01:54 schrieb Mark Kuiphuis:
> 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
>
>
>
> _______________________________________________
> Flow mailing list
> Flow at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow