Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Workflow for Version Control with Workspace

4 posts in General Discussion Last posting was on 2007-11-13 21:49:21.0Z
Gareth Davies Posted on 2007-11-09 11:18:43.0Z
From: Gareth Davies <gruff@sitemaker.cc>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
Newsgroups: sybase.public.workspace.general
Subject: Workflow for Version Control with Workspace
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 87-194-125-184.bethere.co.uk
X-Original-NNTP-Posting-Host: 87-194-125-184.bethere.co.uk
Message-ID: <47344213$1@forums-1-dub>
Date: 9 Nov 2007 03:18:43 -0800
X-Trace: forums-1-dub 1194607123 87.194.125.184 (9 Nov 2007 03:18:43 -0800)
X-Original-Trace: 9 Nov 2007 03:18:43 -0800, 87-194-125-184.bethere.co.uk
Lines: 39
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.workspace.general:525
Article PK: 1088210

The attraction of this product for us is the integration with Eclipse
and Subversion as we've always struggled to nail down a decent version
control workflow with Sybase.

I've read two white papers about Workspace that mention this in passing,
but is there anything more substantial anywhere that explains best
practise around this?

The white papers allude to file-centric workflow, but no granularity is
specified. E.g. one file per DB object? One file for the DB as a whole?

Workspace allows me easily to create a new Stored Procedure and turn
this into a file to version, but I would normally package more than just
the Stored Proc in a file. I would need to add GRANT statements for
example.

Currently we're thinking the easiest workflow is actually going to be at
DB-level. We have two cases to support simultaneously: the
creation/maintenance of Alter scripts to apply to live databases, and
the creation of DB build scripts for daily builds (test) and new
instances of our product. This is the workflow we came up with:
1. Use Workspace to develop stored procs and Aqua/DBVisualizer + SQL
Advantage for DDL work (Workspace just isn't usable yet for DDL/DBA work).
2. Unit test
3. Create Alter scripts manually (if necessary, or see step 6)
4. a) Reverse engineer the dev DB into Powerdesigner PDM. b)Generate
crebas.sql (DB create script) cretrig.sql (procedural script) an
priveleges file.
5. Do a 'modify DB' of this PDM against a pristine copy of the previous
PDM to generate a change script. Compare/edit manually with 3) if
necessary.
6 We now have files for Alter and Create DB which we can then version.

Does this sound reasonable? Are we making it too complicated? Have we
missed anything? What other workflows are recommended/best practice?

Thanks

Gareth


Samir Nigam Posted on 2007-11-09 18:58:27.0Z
From: "Samir Nigam" <samir_dot_nigam@sybase.com>
Newsgroups: sybase.public.workspace.general
References: <47344213$1@forums-1-dub>
Subject: Re: Workflow for Version Control with Workspace
Lines: 65
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: snigamxp.sybase.com
X-Original-NNTP-Posting-Host: snigamxp.sybase.com
Message-ID: <4734add3$1@forums-1-dub>
Date: 9 Nov 2007 10:58:27 -0800
X-Trace: forums-1-dub 1194634707 10.22.85.206 (9 Nov 2007 10:58:27 -0800)
X-Original-Trace: 9 Nov 2007 10:58:27 -0800, snigamxp.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.workspace.general:526
Article PK: 1088211

In the upcoming of WorkSpace (2.0 release), we are planning to release
features
that will make it handy to do version control and simplify your workflow
quite a bit.
WorkSpace will support versioning at the granuarity you like and maintain in
one
consolidated file or multiple files.

We are adding DDL Generation capability in WorkSpace with support for object
granularity as supported by the database, and options like add "if exists
then drop", capture permissions (Grant), and put the DDL in one or multiple
files among others.

Also, WorkSpace will support preview and capture "delta DDL" prior to saving
changes to objects in their respective editors - that means user can save
"alter" commands (where supported by SQL syntax) in a sql file for easy
versioning.

Regards,
Samir

"Gareth Davies" <gruff@sitemaker.cc> wrote in message
news:47344213$1@forums-1-dub...
> The attraction of this product for us is the integration with Eclipse and
> Subversion as we've always struggled to nail down a decent version control
> workflow with Sybase.
>
> I've read two white papers about Workspace that mention this in passing,
> but is there anything more substantial anywhere that explains best
> practise around this?
>
> The white papers allude to file-centric workflow, but no granularity is
> specified. E.g. one file per DB object? One file for the DB as a whole?
>
> Workspace allows me easily to create a new Stored Procedure and turn this
> into a file to version, but I would normally package more than just the
> Stored Proc in a file. I would need to add GRANT statements for example.
>
> Currently we're thinking the easiest workflow is actually going to be at
> DB-level. We have two cases to support simultaneously: the
> creation/maintenance of Alter scripts to apply to live databases, and the
> creation of DB build scripts for daily builds (test) and new instances of
> our product. This is the workflow we came up with:
> 1. Use Workspace to develop stored procs and Aqua/DBVisualizer + SQL
> Advantage for DDL work (Workspace just isn't usable yet for DDL/DBA work).
> 2. Unit test
> 3. Create Alter scripts manually (if necessary, or see step 6)
> 4. a) Reverse engineer the dev DB into Powerdesigner PDM. b)Generate
> crebas.sql (DB create script) cretrig.sql (procedural script) an
> priveleges file.
> 5. Do a 'modify DB' of this PDM against a pristine copy of the previous
> PDM to generate a change script. Compare/edit manually with 3) if
> necessary.
> 6 We now have files for Alter and Create DB which we can then version.
>
> Does this sound reasonable? Are we making it too complicated? Have we
> missed anything? What other workflows are recommended/best practice?
>
> Thanks
>
> Gareth


Gareth Davies Posted on 2007-11-12 10:45:53.0Z
From: Gareth Davies <gruff@sitemaker.cc>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
Newsgroups: sybase.public.workspace.general
Subject: Re: Workflow for Version Control with Workspace
References: <47344213$1@forums-1-dub> <4734add3$1@forums-1-dub>
In-Reply-To: <4734add3$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 87-194-125-184.bethere.co.uk
X-Original-NNTP-Posting-Host: 87-194-125-184.bethere.co.uk
Message-ID: <47382ee1$1@forums-1-dub>
Date: 12 Nov 2007 02:45:53 -0800
X-Trace: forums-1-dub 1194864353 87.194.125.184 (12 Nov 2007 02:45:53 -0800)
X-Original-Trace: 12 Nov 2007 02:45:53 -0800, 87-194-125-184.bethere.co.uk
Lines: 86
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.workspace.general:527
Article PK: 1088213

Thanks Samir, That sounds great. What's the release date for 2.0?

Is the workflow around (say) stored procs changing at all?

Currently, if I were to create mystoredproc.sql, add grant statements
after, a conditional drop before, I would then edit the actual SP on the
database in the next revision; am I to manually copy and paste the code
(once tested) into the .sql file over the correct fragment?

Also, I've noticed that the Text Compare tool in eclipse doesn't work
normally in Workspace. The buttons for copying changes between panes
are not there. This is a shame as this is a really useful tool.

One of the more common use cases we have is we want to compare a DB
against a certain version and diff them. Currently this is very, very
tricky. Any tooling coming to improve this?

Thanks again

Gareth

Samir Nigam wrote:
> In the upcoming of WorkSpace (2.0 release), we are planning to release
> features
> that will make it handy to do version control and simplify your workflow
> quite a bit.
> WorkSpace will support versioning at the granuarity you like and maintain in
> one
> consolidated file or multiple files.
>
> We are adding DDL Generation capability in WorkSpace with support for object
> granularity as supported by the database, and options like add "if exists
> then drop", capture permissions (Grant), and put the DDL in one or multiple
> files among others.
>
> Also, WorkSpace will support preview and capture "delta DDL" prior to saving
> changes to objects in their respective editors - that means user can save
> "alter" commands (where supported by SQL syntax) in a sql file for easy
> versioning.
>
> Regards,
> Samir
>
> "Gareth Davies" <gruff@sitemaker.cc> wrote in message
> news:47344213$1@forums-1-dub...
>> The attraction of this product for us is the integration with Eclipse and
>> Subversion as we've always struggled to nail down a decent version control
>> workflow with Sybase.
>>
>> I've read two white papers about Workspace that mention this in passing,
>> but is there anything more substantial anywhere that explains best
>> practise around this?
>>
>> The white papers allude to file-centric workflow, but no granularity is
>> specified. E.g. one file per DB object? One file for the DB as a whole?
>>
>> Workspace allows me easily to create a new Stored Procedure and turn this
>> into a file to version, but I would normally package more than just the
>> Stored Proc in a file. I would need to add GRANT statements for example.
>>
>> Currently we're thinking the easiest workflow is actually going to be at
>> DB-level. We have two cases to support simultaneously: the
>> creation/maintenance of Alter scripts to apply to live databases, and the
>> creation of DB build scripts for daily builds (test) and new instances of
>> our product. This is the workflow we came up with:
>> 1. Use Workspace to develop stored procs and Aqua/DBVisualizer + SQL
>> Advantage for DDL work (Workspace just isn't usable yet for DDL/DBA work).
>> 2. Unit test
>> 3. Create Alter scripts manually (if necessary, or see step 6)
>> 4. a) Reverse engineer the dev DB into Powerdesigner PDM. b)Generate
>> crebas.sql (DB create script) cretrig.sql (procedural script) an
>> priveleges file.
>> 5. Do a 'modify DB' of this PDM against a pristine copy of the previous
>> PDM to generate a change script. Compare/edit manually with 3) if
>> necessary.
>> 6 We now have files for Alter and Create DB which we can then version.
>>
>> Does this sound reasonable? Are we making it too complicated? Have we
>> missed anything? What other workflows are recommended/best practice?
>>
>> Thanks
>>
>> Gareth
>
>
>


Samir Nigam Posted on 2007-11-13 21:49:21.0Z
From: "Samir Nigam" <samir_dot_nigam@sybase.com>
Newsgroups: sybase.public.workspace.general
References: <47344213$1@forums-1-dub> <4734add3$1@forums-1-dub> <47382ee1$1@forums-1-dub>
Subject: Re: Workflow for Version Control with Workspace
Lines: 135
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: snigamxp.sybase.com
X-Original-NNTP-Posting-Host: snigamxp.sybase.com
Message-ID: <473a1be1$1@forums-1-dub>
Date: 13 Nov 2007 13:49:21 -0800
X-Trace: forums-1-dub 1194990561 10.22.85.206 (13 Nov 2007 13:49:21 -0800)
X-Original-Trace: 13 Nov 2007 13:49:21 -0800, snigamxp.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.workspace.general:528
Article PK: 1088212

Gareth,

AFAIK, the release is set for December but it could change. We can get in
touch with you when it is GA. As for the workflow for versioning stored
procs., I see it being done the following way (in short and assuming start
from new sp). This same scheme could be used for any other database object
as well.

1. Start work by creating a new stored procedure (creates an empty skeleton
with the give name/parameters/variables in the database). Add code, grants
as desired in the sp editor.
2. At the save time you will have option to save it in a sql file
with/without saving to database. SQL file will have grants that you have
added. If you decide to directly save sp in database, you can generate sql
file later by running DDL Gen wizard which will generate the same sql file
for you.
3. At this point, version the sql file to preserve this version of sp.
4. Now as part of debugging/testing, you will make the changes to sp in the
sql file or directly in the database.
4a. If former, versioning is straightforward (file check-in).
4b. If latter, you will have option to save the changes (delta DDL) in a
separate sql file every time you perform save. If that is not suitable,
quickly run the DDL Gen wizard on the sp (and you can select other sps and
objects) and save the full DDL in a sql file like the one saved in step 2
above (use that to overwrite the sql file or save in another sql file). Save
this version of the sql file.

I believe Text compare would work once you have sql files to compare. At
this point, the db compare feature has been discussed internally but has not
been planned for any release. Sorry.

Hope you like WorkSpace 2.0 release.

Regards,
Samir

"Gareth Davies" <gruff@sitemaker.cc> wrote in message
news:47382ee1$1@forums-1-dub...
> Thanks Samir, That sounds great. What's the release date for 2.0?
>
> Is the workflow around (say) stored procs changing at all?
>
> Currently, if I were to create mystoredproc.sql, add grant statements
> after, a conditional drop before, I would then edit the actual SP on the
> database in the next revision; am I to manually copy and paste the code
> (once tested) into the .sql file over the correct fragment?
>
> Also, I've noticed that the Text Compare tool in eclipse doesn't work
> normally in Workspace. The buttons for copying changes between panes are
> not there. This is a shame as this is a really useful tool.
>
> One of the more common use cases we have is we want to compare a DB
> against a certain version and diff them. Currently this is very, very
> tricky. Any tooling coming to improve this?
>
> Thanks again
>
> Gareth
>
> Samir Nigam wrote:
>> In the upcoming of WorkSpace (2.0 release), we are planning to release
>> features
>> that will make it handy to do version control and simplify your workflow
>> quite a bit.
>> WorkSpace will support versioning at the granuarity you like and maintain
>> in one
>> consolidated file or multiple files.
>>
>> We are adding DDL Generation capability in WorkSpace with support for
>> object
>> granularity as supported by the database, and options like add "if exists
>> then drop", capture permissions (Grant), and put the DDL in one or
>> multiple
>> files among others.
>>
>> Also, WorkSpace will support preview and capture "delta DDL" prior to
>> saving
>> changes to objects in their respective editors - that means user can save
>> "alter" commands (where supported by SQL syntax) in a sql file for easy
>> versioning.
>>
>> Regards,
>> Samir
>>
>> "Gareth Davies" <gruff@sitemaker.cc> wrote in message
>> news:47344213$1@forums-1-dub...
>>> The attraction of this product for us is the integration with Eclipse
>>> and
>>> Subversion as we've always struggled to nail down a decent version
>>> control
>>> workflow with Sybase.
>>>
>>> I've read two white papers about Workspace that mention this in passing,
>>> but is there anything more substantial anywhere that explains best
>>> practise around this?
>>>
>>> The white papers allude to file-centric workflow, but no granularity is
>>> specified. E.g. one file per DB object? One file for the DB as a
>>> whole?
>>>
>>> Workspace allows me easily to create a new Stored Procedure and turn
>>> this
>>> into a file to version, but I would normally package more than just the
>>> Stored Proc in a file. I would need to add GRANT statements for
>>> example.
>>>
>>> Currently we're thinking the easiest workflow is actually going to be at
>>> DB-level. We have two cases to support simultaneously: the
>>> creation/maintenance of Alter scripts to apply to live databases, and
>>> the
>>> creation of DB build scripts for daily builds (test) and new instances
>>> of
>>> our product. This is the workflow we came up with:
>>> 1. Use Workspace to develop stored procs and Aqua/DBVisualizer + SQL
>>> Advantage for DDL work (Workspace just isn't usable yet for DDL/DBA
>>> work).
>>> 2. Unit test
>>> 3. Create Alter scripts manually (if necessary, or see step 6)
>>> 4. a) Reverse engineer the dev DB into Powerdesigner PDM. b)Generate
>>> crebas.sql (DB create script) cretrig.sql (procedural script) an
>>> priveleges file.
>>> 5. Do a 'modify DB' of this PDM against a pristine copy of the previous
>>> PDM to generate a change script. Compare/edit manually with 3) if
>>> necessary.
>>> 6 We now have files for Alter and Create DB which we can then version.
>>>
>>> Does this sound reasonable? Are we making it too complicated? Have we
>>> missed anything? What other workflows are recommended/best practice?
>>>
>>> Thanks
>>>
>>> Gareth
>>
>>