Board index » jbuilder » source in database instead in text file

source in database instead in text file


2004-05-04 07:47:38 PM
jbuilder5
A question came to me suddenly ...
If you would writing code editor today, would you make apparatus over text
file, enabling parsing, indexing, caching, etc .... enabiling, in turn all
those browsing, refactoring and autocompletion magic...
... or you would make interface over database, casting SQL queries instead?
Lets say one procedure, or one statement per blob?
With database, you have version control almost by default, and save space
because of normalization.
Easier to implement all those software lifecycle management & statistic
features...
Always can import/export to text.
Triggers could make wonders ... some of them to incrementaly link code and
have application ready to launch (not aplicable to Java).
 
 

Re:source in database instead in text file

Buch wrote:
Quote
A question came to me suddenly ...
If you would writing code editor today, would you make apparatus over text
file, enabling parsing, indexing, caching, etc .... enabiling, in turn all
those browsing, refactoring and autocompletion magic...
... or you would make interface over database, casting SQL queries instead?
Lets say one procedure, or one statement per blob?
With database, you have version control almost by default, and save space
because of normalization.
Easier to implement all those software lifecycle management & statistic
features...
Always can import/export to text.
Triggers could make wonders ... some of them to incrementaly link code and
have application ready to launch (not aplicable to Java).

--
Replace zeroes with "o" to reply


IBM _had_ that with Visual Age. All the code was in a "repository" (aka
proprietary db), and you could check out code that you were going to
modify at a fine grained level (like "method").
Surprise! Developers want their code where they can see it. IBM gave
it up, because it only gained a few (ardent) admirers, and everyone else
hated it.
So now they have Eclipse...
--
Regards,
Lori Olson (TeamB)
 

Re:source in database instead in text file

Buch wrote:
Quote
[ source in database ]
You're basically describing the SmallTalk environment, which had its own
repository format which was designed to be efficient for their IDE and
runtime.
IBM's Visual Age was the direct heir to that concept. With Java, this
is not such a bad idea, as long as :
* There is a way to version-control the sources in a human-manageable
way. It doesn't have to be individual versioning of each "file" or
"class" - a Subversion or Perforce-like (changeset-based) versioning is
fine (in fact, better in a lot of ways).
* there is a way to interchange the source freely with external tools
like Emacs (I don't want to have to use SQLPLUS to edit my Java code :-).
The big problem with SmallTalk and VisualAge was that you were basically
restricted to using their embedded editing and versioning tools (or in
the case of VisualAge, a clumsy interface to external versioning systems).
 

{smallsort}

Re:source in database instead in text file

"Lori M Olson (TeamB)" < XXXX@XXXXX.COM >writes:
Quote
IBM _had_ that with Visual Age. All the code was in a "repository" (aka
proprietary db), and you could check out code that you were going to
modify at a fine grained level (like "method").
The VisualAge line was an apparent attempt at making other languages
(Cobol, Java, C++) conform to the Smalltalk way of doing things. But
it was too alien to the Algol language family.
 

Re:source in database instead in text file

Quote
The big problem with SmallTalk and VisualAge was that you were basically
restricted to using their embedded editing and versioning tools (or in
the case of VisualAge, a clumsy interface to external versioning systems).
So, the problem was (like Lori also said) that repository was in proprietary
database.
If it was in open-source database, would it make the difference?
Speaking of open-source databases, its kind of difficult to pick candidate
for that - mysql does not have reliable stored procedures (yet), and
Interbase has security problem.
What would you choose?
 

Re:source in database instead in text file

"Buch" < XXXX@XXXXX.COM >writes:
Quote
So, the problem was (like Lori also said) that repository was in proprietary
database.
If it was in open-source database, would it make the difference?
It's the format(s) that need to be open, not necessarily the
database. You could store the image in a BLOB in an OSS database and
it would still be proprietary because you would need to know the
semantics of the Smalltalk image binary.