You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Tiago Espinha <ti...@yahoo.co.uk> on 2010/03/12 21:00:54 UTC
Google Summer of Code
Dear all,
My name is Tiago Espinha and I participated in last year's edition of Google Summer of Code. I've decided to participate again this year and after speaking with Kathey (my mentor from last year) she suggested that I'd take on her DERBY-728. This issue seems overly complex for a newcomer and I've had previous experience with contributing to Derby.
With this said, I'm taking on this issue for now and apply for GSoC with this issue in mind. I know that when it comes to GSoC, Apache will have to submit a list of possible projects for students to apply for. Is it possible that this is one of the possible projects? Or will I have to apply under "derby-testandfix"?
In conversation with Kathey, I also considered another possibility, but for this I'd like some input from the community. This year I'm doing a Master's degree in Advanced Software Engineering, and I thought that perhaps it would be possible to take a Derby project as my Master's thesis. My department allows me to submit my own idea, but what I would like to know is if there is any outstanding, cutting-edge feature that we could possibly integrate into Derby, even if just in an experimental basis.
On my course, there are two main focuses: service oriented architectures (web services and all aspects related to web service modelling) and model driven development (MDD). I'm not sure how familiar you are with the concept of MDD, as it does not seem to be something with a lot of hype surrounding it, but I think it could possibly be a good concept to apply to Derby. I've just been introduced this year to this concept and basically it boils down to generating code from models. So instead of writing Java code, we simply create a model and generate code from that; apparently this is being used in some companies and most of the times up to 90% of the code can be generated automatically. The remaining 10% are written by hand afterwards.
This is just food for thought, if you know of any other issues/features that would make a good thesis subject, I'm open to suggestion.
For now, however, I'll be taking on DERBY-728.
Regards,
Tiago Espinha
Re: Google Summer of Code
Posted by Tiago Espinha <ti...@yahoo.co.uk>.
Dear John,
I'm not sure one of these topics would be suitable for my thesis, so I think for now I'll just stick with DERBY-728 and make my GSoC application based on this, with Kathey as my mentor. Thank you for the list though.
Tiago
________________________________
From: Ян Программист <we...@gmail.com>
To: derby-dev@db.apache.org; tiago.derby@yahoo.co.uk
Sent: Sat, 13 March, 2010 9:15:20
Subject: Re: Google Summer of Code
Very interesting. And I am also having some interesting ideas for
participating in Google soc. Here some of them:
JavaDB enchantments
Main disadvantages of official JavaDB build
* JDBC only connector
* JDBC is catastrophically slow
* SQL reusing does not solve architecture problems
* Embed configuration is not always possible/sometimes is not
always desirable
* There is no storage engine porting available(JavaDB storage
engines are not compatible for non-Java databases)
* Importing/exporting of DDL of other database vendors. Bad
migration from Oracle/SQL Server/PostreSQL/MySQL/MSQL/HyperSQL
* Is not clearly understood how to inject additional JOIN/UNION
algorithms/strategies
* SQL result records could not be transformed afterwards but
before sent to client lib – all transformations are extra heavy for
client application
* Custom column types, serialization and indexing support for
those custom types – nothing serious at this moment
* No actual compatibility tests for Oracle, SQL Server
What would be great to be supported in JavaDB
* Java to bytecode & bytecode to native build with configuring
what parts to be built as native C/C++ and called via JNI and what
features to be configured on
* Sun Studio tests tools for JNI and JavaDB in particular:
* Java to C
* C to Java
* C to Java to C
* Java – C – Java
* Performance tips for JVM/Sun Studio/JNI over JVM
* OpenSolaris/Solaris configuration
* libumem with JNI
* SQL support transforming SELECT requests – data transformations
* WSDL publishing when deploying JavaDB
* XML formatter unlike binary. Less speed but more flexibility
* AXIS for publishing Java objects as Web services
* Implementing other gateways:
* Servlet
* Applet
* HTTP Server
* As a variantRESTful: less URL length -& better carrying capacity
* Stress testing for qualified stability and failure-resistance
* Table columns extensibility
* Floating row count extensibility
* Importing JavaDB configuration from XML on-the-fly
* RPC support based on JavaDB core
* Ability to build JavaDB with embed RPC support
* JDBC support could be switched on/off(thus RPC could be primary
tactic for client connectivity)
* VIEWS generation support from XML, SQL + XML
* Same as in (11) but usinghttp://xmlrpc-c.sourceforge.net/from
the client side
* libumem +http://xmlrpc-c.sourceforge.net/threw Sun Studio compiler support
* HTTP routes for HTTP server gateway:
* Route redirections for separate JavaDB/Derby servers
* Hot plug of redirection configurations instead of long & heavy
files like .htaccess
* Caching support for HTTP routes
* Mirroring from the side of HSQLDB http gateway implementation
(JavaDB + HSQLDB replication)
* JavaDB with MQ support performance:
* JavaDB using non-embed configuration with separated ActiveMQ broker
* Swapping between different message brokers at runtime
* JavaDB embed into JMS broker
* Implementing an SQL storage engine, in witch a BLACKHOLE-like
table where inserted rows via SQL will be automatically grabbed with
message broker and sent to specific endpoint
* RabbitMQ broker
* ActiveMQ as Java solution vs RabbitMQ as R-lang based solution
* WebDAV with JavaDB as storage with embed/non-embed configuration
on Sun Java System Web Server
* Good idea is to use memcacheq – when there is cached messages
and cached redirects
* Using Java Fork/Join Framework for JavaDB/JMS queues
* Implementation of joining two or more message streams at runtime
* While joining several streams to one joining of messages should
be prioritized
* Implementation of on-the-fly swap of two messages from parallel
message streams (but with same priority on both for compatibility with
priorities features)
* Priority-driven SQLs
* Swap/join SQL result(data) capabilities
* Client-side plug-in for automated in-place injection (useful
mostly for Web applications)
* Format would support: JSON/YAML/XML/Bytecode format, AMF0, AMF3
Connect to a community discuss, Tiago! John
2010/3/12 Tiago Espinha <ti...@yahoo.co.uk>:
> Dear all,
>
> My name is Tiago Espinha and I participated in last year's edition of Google
> Summer of Code. I've decided to participate again this year and after
> speaking with Kathey (my mentor from last year) she suggested that I'd take
> on her DERBY-728. This issue seems overly complex for a newcomer and I've
> had previous experience with contributing to Derby.
> With this said, I'm taking on this issue for now and apply for GSoC with
> this issue in mind. I know that when it comes to GSoC, Apache will have to
> submit a list of possible projects for students to apply for. Is it possible
> that this is one of the possible projects? Or will I have to apply under
> "derby-testandfix"?
> In conversation with Kathey, I also considered another possibility, but for
> this I'd like some input from the community. This year I'm doing a Master's
> degree in Advanced Software Engineering, and I thought that perhaps it would
> be possible to take a Derby project as my Master's thesis. My department
> allows me to submit my own idea, but what I would like to know is if there
> is any outstanding, cutting-edge feature that we could possibly integrate
> into Derby, even if just in an experimental basis.
> On my course, there are two main focuses: service oriented architectures
> (web services and all aspects related to web service modelling) and model
> driven development (MDD). I'm not sure how familiar you are with the concept
> of MDD, as it does not seem to be something with a lot of hype surrounding
> it, but I think it could possibly be a good concept to apply to Derby. I've
> just been introduced this year to this concept and basically it boils down
> to generating code from models. So instead of writing Java code, we simply
> create a model and generate code from that; apparently this is being used in
> some companies and most of the times up to 90% of the code can be generated
> automatically. The remaining 10% are written by hand afterwards.
> This is just food for thought, if you know of any other issues/features that
> would make a good thesis subject, I'm open to suggestion.
> For now, however, I'll be taking on DERBY-728.
> Regards,
> Tiago Espinha
>
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
Said. So, no variants this year? That is sad. By the way - she will have a
student this year. So I can wait a year, doing some development outside of
Google soc, to participate in 2011. But I think there is a grate chance for
me for success in case if senior developer is mentor(like you). That is the
most awesome situation ever ;) John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
> I would be willing to serve as a mentor for a GSoC intern who was working
> on this project.
So, you would like to be my mentor on this?
> If you are interested in pursuing this, I think the next step would be to
> develop the initial seed of an idea into a more fully-fleshed-out project
> proposal. For example:
Yeap, I am interested. Especially if end-users (read: developers) will
use object relational mapping, for example, if some entity
properties(class fields in ORM) will stand on JavaDB
data types and some fields would be from MySQL(Oracle? DB2?). In the
area where few databases used in parallel. Especially awesome for
Oracle MQ tables, which force message broker to send(recieve?) data
entries, updated/inserted using SQL; for data centric stuff. That was
a main idea
> - do some research to try to locate existing compatibility test suites
> that we could start with
Column types compatibility?
> - identify likely areas of behavior difference where test suites could
> expose interesting issues
I will think deeply to generate a reasonable list
> - sketch out the mechanics of how we'd use these test suites to verify
> Derby compatibility behaviors in an ongoing fashion (that is, how can
> we automate the compatibility testing, how can we interpret the results,
> etc.)
I suppose you are about compatibility assertion-like test? Performance
test to count time issues of data conversions (e.g. one numeric type
to another, text to blob and vice versa, etc.)?
> The best place to record these ideas is in the JIRA issue itself; you should
> assign the issue to yourself to indicate that you are working on it.
1. A more detailed list please. Step by step. So I could get all in focus
2. I will figure out how to assign it to me
John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
> I would be willing to serve as a mentor for a GSoC intern who was working
> on this project.
So, you would like to be my mentor on this?
> If you are interested in pursuing this, I think the next step would be to
> develop the initial seed of an idea into a more fully-fleshed-out project
> proposal. For example:
Yeap, I am interested. Especially if end-users (read: developers) will
use object relational mapping, for example, if some entity
properties(class fields in ORM) will stand on JavaDB
data types and some fields would be from MySQL(Oracle? DB2?). In the
area where few databases used in parallel. Especially awesome for
Oracle MQ tables, which force message broker to send(recieve?) data
entries, updated/inserted using SQL; for data centric stuff. That was
a main idea
> - do some research to try to locate existing compatibility test suites
> that we could start with
Column types compatibility?
> - identify likely areas of behavior difference where test suites could
> expose interesting issues
I will think deeply to generate a reasonable list
> - sketch out the mechanics of how we'd use these test suites to verify
> Derby compatibility behaviors in an ongoing fashion (that is, how can
> we automate the compatibility testing, how can we interpret the results,
> etc.)
I suppose you are about compatibility assertion-like test? Performance
test to count time issues of data conversions (e.g. one numeric type
to another, text to blob and vice versa, etc.)?
> The best place to record these ideas is in the JIRA issue itself; you should
> assign the issue to yourself to indicate that you are working on it.
1. A more detailed list please. Step by step. So I could get all in focus
2. I will figure out how to assign it to me
John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
Oh, yeah, the XML type in Oracle is for ORM stuff, that's for shure ;) John
2010/3/17 Ян Программист <we...@gmail.com>
>
>
> 2010/3/17 Ян Программист <we...@gmail.com>:
>
> >> * No actual compatibility tests for Oracle, SQL Server
> >>
> >>
> >>
> >> I imagine that there are some existing compatibility test suites out
> here. It would be interesting to understand Derby's compatibility with other
> databases. This sounds like a task >on which a GSoC student could make good
> progress.
> >
> > Thanks,
> > -Rick
> >
> Well, some useful compatibility features to focus on:
>
>
> 1. Converting data from one database to another in a respective way
> against data consistency. The reasons why special software for converting
> between different databases is useless. Problem of different actual length
> of data in table cells. Acceptableness of creation and population of data
> entries in additional tables with equal column structure for columns (read:
> table schema) for entries with incompatible sizes (for column types of
> consuming tables in a consuming database)
> 2. Converting data in a entity centric manner. Convert data of similar
> column types from a point of stored data. If the database client code
> contain strategy switching logic of how to interpret the state of data,
> described in database, it is possible to populate entries in other tables of
> consuming database to avoid loss of data consistency
> 3. Converting types is not always good. Compatibility is rather is if
> consuming database would read entries with a special formatter - to
> interpret data as it's own type. So you can copy data as binary heap and
> force consuming database to enable special formatter to read data even at
> production enviroment (formatter would rather point on certain points of a
> cell data chunk in each number/word/... of actually represented data to
> avoid dealing with useless binary delimiters). But that is for data types
> which is for representing the same class (numeric-to-numeric, date-to-date).
> Stored data in cells could be forced to converted to native to avoid usage
> of special formatter, to use normal formatter when consistency of state of
> entities(ORM?), represented in entries is ensured.
> 4. Column type compatibility is not an index compatibility. Source
> database contains lots of indexes to speed the JOINs. So it is normally
> required for consuming database to force indexing consumed data entries.
> Index simply represent positions of cells, so in different databases it
> would be different positions for the same data due to cell data size &
> binary delimiters (a part of storage engine stuff). But delimiters are the
> same for same storage engine, cell data sizes vary from to cell. Still do
> not know how to fix a problem - but it would be awesome to apply, for
> example, MySQL indexes on JavaDB without re-indexing on JavaDB side
> 5. I see a VARBINARY as a candidate for dealing with aggregation in
> ORM. When you will need a convertion due to any reasons - you can get entity
> data, described in ORM classes with ORM, where aggregated entities are
> virtualised with referencing columns on either table, you can get entries
> from aggregated table (entry of property set of entity) and store it into
> VARBINARY of consuming database, and because it is known how the ORM class
> entries would be iterated in tables of consumer database - you can read at
> consumer side in a binary formatter, and use that data how you want.
> Convertion of consumer's database VARBINARY to a set of columns as native
> ones for aggregated entity entries is fast enough(?)
> 6. All that numeric precision delaing stuff. Yeap, ODBC NUMERIC type
> will not have any sence if column compatibility would be implemented
> (precision auto-dealing when reading from cells with different length (count
> of digits) and float-to-int and other stuff). Can help avoiding some ODBC
> code, as also as JDBC code, both relative to column type handling, when
> accessing data from non-native database clients( access JavaDB from C# or
> SQLite from Java, for example)
>
> *XML persistence driven conversions* of both schema and data and *"hot"
> binary copying* of non-native data from different databases(special
> formatters in (1)) are two main goals here. John
>
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
I was meaning that assertions against SQL execution would require to
dynamically generate SQL code for various data types. To ensure running
PostgreSQL code on MySQL and vice versa. If you are talking about JDBC
connectivity - I suppose would be needed some kind of trigger handling
for debugging a strategy of data conversions. Explain please. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0008482.htm
Is this in focus? John
Re: Google Summer of Code
Posted by Bryan Pendleton <br...@gmail.com>.
> types compatibility. I thought the main focus in SQL variations that
> force different strategies of data conversion when executing statements.
I agree that there are many aspects to the question of compatibility.
SQL Variations are one of them, datatypes and data conversions are
certainly another.
I think that Derby has room for improvement in all of these areas.
The basic goal, in my mind, is to identify those situations where
Derby has a different behavior than other database systems, and to
understand what is causing those differences, and whether they reveal
flaws in Derby.
thanks,
bryan
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
That is clearly understood. And how it is connected to the things against
data types? You wrote that that it make sense to figure out data types
compatibility. I thought the main focus in SQL variations that force
different strategies of data conversion when executing statements. Explain.
John
2010/3/17 Bryan Pendleton <br...@gmail.com>
> ?? ??????????? wrote:
>
>> No, not understood. You are focusing on JDBC compatibility from the
>> database side? Or you looking for compatibility of types, not provided to
>> JDBC? There are convertions to generic* types due to JDBC connectivity
>> issues... SQL code would run in most cases, but data would not always be
>> consistent. Consistency is a MUST, as I understood (?). Explain more
>> detailed. John
>>
>
> Hi John,
>
> It is true that SQL code runs in most cases, but there are many small
> variations between the precise features of SQL that are supported by
> the various database implementations.
>
> Consider, for example, the ORDER BY clause.
>
> Most database systems allow ORDER BY to be present in simple SELECT
> statements:
>
> select id, firstname, lastname from employee order by lastname
>
> This has been part of the SQL standard for 20 years and is widely
> supported.
>
> However, there are lots of variations on this SQL statement. For example,
> is it supported to use ORDER BY on a column which is not present in the
> SELECT
> list, as in:
>
> select id from employee order by lastname
>
> Or, is it supported to use ORDER BY on an expression, as in:
>
> select lastname from employee order by lower(lastname)
>
> Or, is it supported to use ORDER BY in a sub-query, as in:
>
> select * from (select lastname from employee order by lastname) t
>
> Over the years, we have tracked down many such variations of SQL
> statements, and
> explored the issues of how Derby's support for SQL compares to the support
> provided by databases such as MySQL or Postgres (or others).
>
> These are the sorts of compatibility issues I was particularly referring
> to.
>
> thanks,
>
> bryan
>
>
Re: Google Summer of Code
Posted by Bryan Pendleton <br...@gmail.com>.
?? ??????????? wrote:
> No, not understood. You are focusing on JDBC compatibility from the
> database side? Or you looking for compatibility of types, not provided
> to JDBC? There are convertions to generic* types due to JDBC
> connectivity issues... SQL code would run in most cases, but data would
> not always be consistent. Consistency is a MUST, as I understood (?).
> Explain more detailed. John
Hi John,
It is true that SQL code runs in most cases, but there are many small
variations between the precise features of SQL that are supported by
the various database implementations.
Consider, for example, the ORDER BY clause.
Most database systems allow ORDER BY to be present in simple SELECT statements:
select id, firstname, lastname from employee order by lastname
This has been part of the SQL standard for 20 years and is widely supported.
However, there are lots of variations on this SQL statement. For example,
is it supported to use ORDER BY on a column which is not present in the SELECT
list, as in:
select id from employee order by lastname
Or, is it supported to use ORDER BY on an expression, as in:
select lastname from employee order by lower(lastname)
Or, is it supported to use ORDER BY in a sub-query, as in:
select * from (select lastname from employee order by lastname) t
Over the years, we have tracked down many such variations of SQL statements, and
explored the issues of how Derby's support for SQL compares to the support
provided by databases such as MySQL or Postgres (or others).
These are the sorts of compatibility issues I was particularly referring to.
thanks,
bryan
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
No, not understood. You are focusing on JDBC compatibility from the database
side? Or you looking for compatibility of types, not provided to JDBC? There
are convertions to generic* types due to JDBC connectivity issues... SQL
code would run in most cases, but data would not always be consistent.
Consistency is a MUST, as I understood (?). Explain more detailed. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
Understood. John
Re: Google Summer of Code
Posted by Bryan Pendleton <bp...@gmail.com>.
Ян Программист wrote:
> >> * No actual compatibility tests for Oracle, SQL Server
> >>
> >> I imagine that there are some existing compatibility test suites
> out here. It would be interesting to understand Derby's compatibility
> with other databases. This sounds like a task >on which a GSoC student
> could make good progress.
> >
> > Thanks,
> > -Rick
> >
> Well, some useful compatibility features to focus on:
I think your observations are quite interesting, and highlight some areas
where compatibility problems may arise.
But I think we are specifically interested in the idea of compatibility
*tests* which we could use to demonstrate compatibility with Oracle, SQL Server,
MySQL, Postgres, etc.
Are there existing compatibility test suites out there? Can you research this?
What would it take to run those tests against a variety of implementations,
including both Derby and others?
How could we automate that process so that we could add it to our test
suites and keep it up to date over time?
We have some existing information about Derby compatibility in our wiki:
- http://wiki.apache.org/db-derby/SQLvsDerbyFeatures
- http://wiki.apache.org/db-derby/JDBCSupport
- http://wiki.apache.org/db-derby/PlatformTestsDerby
What would we need to do in order to be able to write a similar page which
discusses Derby compatibility with, e.g., MySQL and/or Postgres? That is,
what tests do we have to run to gather this information?
One place to start would be to see if either MySQL or Postgres have existing
SQL-compliance or JDBC-compliance suites that we could run against Derby to
compare the results.
thanks,
bryan
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
Generating proper SQL for concrete database is a responsibility of ORM. And
the compatibility I was talking is column type compatibility itself, NOT SQL
syntax compatibility. Stop squashing original context!
Column type compatibility is a way to remove JDBC neediness. Besides, I
already mentioned about accessing JavaDB from C/C++ client. And who said
that there will be Java client?!
I hate JDBC! John
Re: Google Summer of Code
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi John,
I agree with Bryan that we want to compare Derby's behavior to that of
other databases so that we can understand
1) where Derby diverges from the SQL Standard
2) what features we should add to Derby to increase its usefulness
As you note, datatypes are an important compatibility topic. I think
that you are on the right track when you talk about ORM frameworks. I
think that we would understand a great deal about datatype compatibility
by studying how the major ORM frameworks map datatypes onto various
rdbmses. The engineers at Hibernate, Toplink, etc. have done a lot of
the analysis already. A systematic compilation of their findings would
be useful.
Thanks,
-Rick
Ян Программист wrote:
>
>
> 2010/3/17 Ян Программист <webautomator@gmail.com
> <ma...@gmail.com>>:
> >> * No actual compatibility tests for Oracle, SQL Server
> >>
> >>
> >>
> >> I imagine that there are some existing compatibility test suites
> out here. It would be interesting to understand Derby's compatibility
> with other databases. This sounds like a task >on which a GSoC student
> could make good progress.
> >
> > Thanks,
> > -Rick
> >
> Well, some useful compatibility features to focus on:
>
> 1. Converting data from one database to another in a respective way
> against data consistency. The reasons why special software for
> converting between different databases is useless. Problem of
> different actual length of data in table cells. Acceptableness
> of creation and population of data entries in additional tables
> with equal column structure for columns (read: table schema) for
> entries with incompatible sizes (for column types of consuming
> tables in a consuming database)
> 2. Converting data in a entity centric manner. Convert data of
> similar column types from a point of stored data. If the
> database client code contain strategy switching logic of how to
> interpret the state of data, described in database, it is
> possible to populate entries in other tables of consuming
> database to avoid loss of data consistency
> 3. Converting types is not always good. Compatibility is rather is
> if consuming database would read entries with a special
> formatter - to interpret data as it's own type. So you can copy
> data as binary heap and force consuming database to enable
> special formatter to read data even at production enviroment
> (formatter would rather point on certain points of a cell data
> chunk in each number/word/... of actually represented data to
> avoid dealing with useless binary delimiters). But that is for
> data types which is for representing the same class
> (numeric-to-numeric, date-to-date). Stored data in cells could
> be forced to converted to native to avoid usage of special
> formatter, to use normal formatter when consistency of state of
> entities(ORM?), represented in entries is ensured.
> 4. Column type compatibility is not an index compatibility. Source
> database contains lots of indexes to speed the JOINs. So it is
> normally required for consuming database to force indexing
> consumed data entries. Index simply represent positions of
> cells, so in different databases it would be different positions
> for the same data due to cell data size & binary delimiters (a
> part of storage engine stuff). But delimiters are the same for
> same storage engine, cell data sizes vary from to cell. Still do
> not know how to fix a problem - but it would be awesome to
> apply, for example, MySQL indexes on JavaDB without re-indexing
> on JavaDB side
> 5. I see a VARBINARY as a candidate for dealing with aggregation in
> ORM. When you will need a convertion due to any reasons - you
> can get entity data, described in ORM classes with ORM, where
> aggregated entities are virtualised with referencing columns on
> either table, you can get entries from aggregated table (entry
> of property set of entity) and store it into VARBINARY of
> consuming database, and because it is known how the ORM class
> entries would be iterated in tables of consumer database - you
> can read at consumer side in a binary formatter, and use that
> data how you want. Convertion of consumer's database VARBINARY
> to a set of columns as native ones for aggregated entity entries
> is fast enough(?)
> 6. All that numeric precision delaing stuff. Yeap, ODBC NUMERIC
> type will not have any sence if column compatibility would be
> implemented (precision auto-dealing when reading from cells with
> different length (count of digits) and float-to-int and other
> stuff). Can help avoiding some ODBC code, as also as JDBC code,
> both relative to column type handling, when accessing data from
> non-native database clients( access JavaDB from C# or SQLite
> from Java, for example)
>
> *XML persistence driven conversions* of both schema and data and
> *"hot" binary copying* of non-native data from different
> databases(special formatters in (1)) are two main goals here. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
2010/3/17 Ян Программист <we...@gmail.com>:
>> * No actual compatibility tests for Oracle, SQL Server
>>
>>
>>
>> I imagine that there are some existing compatibility test suites out
here. It would be interesting to understand Derby's compatibility with other
databases. This sounds like a task >on which a GSoC student could make good
progress.
>
> Thanks,
> -Rick
>
Well, some useful compatibility features to focus on:
1. Converting data from one database to another in a respective way
against data consistency. The reasons why special software for converting
between different databases is useless. Problem of different actual length
of data in table cells. Acceptableness of creation and population of data
entries in additional tables with equal column structure for columns (read:
table schema) for entries with incompatible sizes (for column types of
consuming tables in a consuming database)
2. Converting data in a entity centric manner. Convert data of similar
column types from a point of stored data. If the database client code
contain strategy switching logic of how to interpret the state of data,
described in database, it is possible to populate entries in other tables of
consuming database to avoid loss of data consistency
3. Converting types is not always good. Compatibility is rather is if
consuming database would read entries with a special formatter - to
interpret data as it's own type. So you can copy data as binary heap and
force consuming database to enable special formatter to read data even at
production enviroment (formatter would rather point on certain points of a
cell data chunk in each number/word/... of actually represented data to
avoid dealing with useless binary delimiters). But that is for data types
which is for representing the same class (numeric-to-numeric, date-to-date).
Stored data in cells could be forced to converted to native to avoid usage
of special formatter, to use normal formatter when consistency of state of
entities(ORM?), represented in entries is ensured.
4. Column type compatibility is not an index compatibility. Source
database contains lots of indexes to speed the JOINs. So it is normally
required for consuming database to force indexing consumed data entries.
Index simply represent positions of cells, so in different databases it
would be different positions for the same data due to cell data size &
binary delimiters (a part of storage engine stuff). But delimiters are the
same for same storage engine, cell data sizes vary from to cell. Still do
not know how to fix a problem - but it would be awesome to apply, for
example, MySQL indexes on JavaDB without re-indexing on JavaDB side
5. I see a VARBINARY as a candidate for dealing with aggregation in ORM.
When you will need a convertion due to any reasons - you can get entity
data, described in ORM classes with ORM, where aggregated entities are
virtualised with referencing columns on either table, you can get entries
from aggregated table (entry of property set of entity) and store it into
VARBINARY of consuming database, and because it is known how the ORM class
entries would be iterated in tables of consumer database - you can read at
consumer side in a binary formatter, and use that data how you want.
Convertion of consumer's database VARBINARY to a set of columns as native
ones for aggregated entity entries is fast enough(?)
6. All that numeric precision delaing stuff. Yeap, ODBC NUMERIC type will
not have any sence if column compatibility would be implemented (precision
auto-dealing when reading from cells with different length (count of digits)
and float-to-int and other stuff). Can help avoiding some ODBC code, as also
as JDBC code, both relative to column type handling, when accessing data
from non-native database clients( access JavaDB from C# or SQLite from Java,
for example)
*XML persistence driven conversions* of both schema and data and *"hot"
binary copying* of non-native data from different databases(special
formatters in (1)) are two main goals here. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
> * No actual compatibility tests for Oracle, SQL Server
>
>
>
> I imagine that there are some existing compatibility test suites out here. It would be interesting to understand Derby's compatibility with other databases. This sounds like a task >on which a GSoC student could make good progress.
Thanks,
-Rick
Well, some useful compatibility features to focus on:
1.
Re: Google Summer of Code
Posted by Bryan Pendleton <bp...@gmail.com>.
> Ян Программист wrote:
>> * No actual compatibility tests for Oracle, SQL Server
>>
>>
>> I imagine that there are some existing compatibility test suites
>> out here. It would be interesting to understand Derby's
>> compatibility with other databases. This sounds like a task on
>> which a GSoC student could make good progress.
>>
>> Thanks,
>> -Rick
>>
>> Can you recommend a mentor for such task?
Hi John,
This does sound like an excellent idea for a Google Summer of Code project.
I have created issue DERBY-4586 in the Jira system to record the initial
thoughts on this (https://issues.apache.org/jira/browse/DERBY-4586)
I would be willing to serve as a mentor for a GSoC intern who was working
on this project.
If you are interested in pursuing this, I think the next step would be to
develop the initial seed of an idea into a more fully-fleshed-out project
proposal. For example:
- do some research to try to locate existing compatibility test suites
that we could start with
- identify likely areas of behavior difference where test suites could
expose interesting issues
- sketch out the mechanics of how we'd use these test suites to verify
Derby compatibility behaviors in an ongoing fashion (that is, how can
we automate the compatibility testing, how can we interpret the results, etc.)
The best place to record these ideas is in the JIRA issue itself; you should
assign the issue to yourself to indicate that you are working on it.
thanks,
bryan
Re: Google Summer of Code
Posted by Rick Hillegas <Ri...@Sun.COM>.
Ян Программист wrote:
> * No actual compatibility tests for Oracle, SQL Server
>
>
> I imagine that there are some existing compatibility test suites
> out here. It would be interesting to understand Derby's
> compatibility with other databases. This sounds like a task on
> which a GSoC student could make good progress.
>
> Thanks,
> -Rick
>
> Can you recommend a mentor for such task?
Hi John,
I think that Kathey is the only committer who has indicated she will
have time this year to mentor a GSoC project.
Thanks,
-Rick
>
>
>
> By the way - what about RESTful adapter? To access JavaDB data entries
> threw service layer? I am having developer related expirience rather
> in Web technologies, so I am quite interested in such a thing a lot
> (independently of Google suc)...
>
> Serialization is also a hot topic for Web developer....
>
> Respond please. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
* No actual compatibility tests for Oracle, SQL Server
>
>>
> I imagine that there are some existing compatibility test suites out here.
> It would be interesting to understand Derby's compatibility with other
> databases. This sounds like a task on which a GSoC student could make good
> progress.
>
> Thanks,
> -Rick
>
Can you recommend a mentor for such task?
By the way - what about RESTful adapter? To access JavaDB data entries threw
service layer? I am having developer related expirience rather in Web
technologies, so I am quite interested in such a thing a lot (independently
of Google suc)...
Serialization is also a hot topic for Web developer....
Respond please. John
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
I think that it is reasonable for JavaDB project to focus Web developers on
such a database. And one thing about automatic (read: stress) testing is
kind of tools for generating both database side test code & web scripting
code (PHP 5, Java, etc.) testing code. Unit test frameworks is a good thing,
- but all those database testing tools do not generate testing code, they
execute binary stuff in memory from client side (read: performing stress).
This is a big minus, huge one for Web developers. John
Re: Google Summer of Code
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi John,
I think you have proposed a lot of very interesting projects. Here are
my comments on some of them. However, I'm afraid that I cannot commit
the time this year to be an offical GSoC mentor.
Ян Программист wrote:
> ...
>
> * There is no storage engine porting available(JavaDB storage
> engines are not compatible for non-Java databases)
>
This sounds very useful athough the devil is in the details. Are you
thinking about mapping the Store api
(org.apache.derby.iapi.store.access.*) to some smaller api which is
easier to port?
> ...
>
> * Custom column types, serialization and indexing support for
> those custom types – nothing serious at this moment
>
10.6 introduces custom types (see DERBY-651). There is substantial
support in Derby for being able to compare and index types which
implement java.lang.Comparable--however, that support is disabled right
now. Enabling that support would be a smallish, focussed, useful task.
> * No actual compatibility tests for Oracle, SQL Server
>
I imagine that there are some existing compatibility test suites out
here. It would be interesting to understand Derby's compatibility with
other databases. This sounds like a task on which a GSoC student could
make good progress.
Thanks,
-Rick
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
Very interesting. And I am also having some interesting ideas for
participating in Google soc. Here some of them:
JavaDB enchantments
Main disadvantages of official JavaDB build
* JDBC only connector
* JDBC is catastrophically slow
* SQL reusing does not solve architecture problems
* Embed configuration is not always possible/sometimes is not
always desirable
* There is no storage engine porting available(JavaDB storage
engines are not compatible for non-Java databases)
* Importing/exporting of DDL of other database vendors. Bad
migration from Oracle/SQL Server/PostreSQL/MySQL/MSQL/HyperSQL
* Is not clearly understood how to inject additional JOIN/UNION
algorithms/strategies
* SQL result records could not be transformed afterwards but
before sent to client lib – all transformations are extra heavy for
client application
* Custom column types, serialization and indexing support for
those custom types – nothing serious at this moment
* No actual compatibility tests for Oracle, SQL Server
What would be great to be supported in JavaDB
* Java to bytecode & bytecode to native build with configuring
what parts to be built as native C/C++ and called via JNI and what
features to be configured on
* Sun Studio tests tools for JNI and JavaDB in particular:
* Java to C
* C to Java
* C to Java to C
* Java – C – Java
* Performance tips for JVM/Sun Studio/JNI over JVM
* OpenSolaris/Solaris configuration
* libumem with JNI
* SQL support transforming SELECT requests – data transformations
* WSDL publishing when deploying JavaDB
* XML formatter unlike binary. Less speed but more flexibility
* AXIS for publishing Java objects as Web services
* Implementing other gateways:
* Servlet
* Applet
* HTTP Server
* As a variantRESTful: less URL length -& better carrying capacity
* Stress testing for qualified stability and failure-resistance
* Table columns extensibility
* Floating row count extensibility
* Importing JavaDB configuration from XML on-the-fly
* RPC support based on JavaDB core
* Ability to build JavaDB with embed RPC support
* JDBC support could be switched on/off(thus RPC could be primary
tactic for client connectivity)
* VIEWS generation support from XML, SQL + XML
* Same as in (11) but usinghttp://xmlrpc-c.sourceforge.net/from
the client side
* libumem +http://xmlrpc-c.sourceforge.net/threw Sun Studio compiler support
* HTTP routes for HTTP server gateway:
* Route redirections for separate JavaDB/Derby servers
* Hot plug of redirection configurations instead of long & heavy
files like .htaccess
* Caching support for HTTP routes
* Mirroring from the side of HSQLDB http gateway implementation
(JavaDB + HSQLDB replication)
* JavaDB with MQ support performance:
* JavaDB using non-embed configuration with separated ActiveMQ broker
* Swapping between different message brokers at runtime
* JavaDB embed into JMS broker
* Implementing an SQL storage engine, in witch a BLACKHOLE-like
table where inserted rows via SQL will be automatically grabbed with
message broker and sent to specific endpoint
* RabbitMQ broker
* ActiveMQ as Java solution vs RabbitMQ as R-lang based solution
* WebDAV with JavaDB as storage with embed/non-embed configuration
on Sun Java System Web Server
* Good idea is to use memcacheq – when there is cached messages
and cached redirects
* Using Java Fork/Join Framework for JavaDB/JMS queues
* Implementation of joining two or more message streams at runtime
* While joining several streams to one joining of messages should
be prioritized
* Implementation of on-the-fly swap of two messages from parallel
message streams (but with same priority on both for compatibility with
priorities features)
* Priority-driven SQLs
* Swap/join SQL result(data) capabilities
* Client-side plug-in for automated in-place injection (useful
mostly for Web applications)
* Format would support: JSON/YAML/XML/Bytecode format, AMF0, AMF3
Connect to a community discuss, Tiago! John
2010/3/12 Tiago Espinha <ti...@yahoo.co.uk>:
> Dear all,
>
> My name is Tiago Espinha and I participated in last year's edition of Google
> Summer of Code. I've decided to participate again this year and after
> speaking with Kathey (my mentor from last year) she suggested that I'd take
> on her DERBY-728. This issue seems overly complex for a newcomer and I've
> had previous experience with contributing to Derby.
> With this said, I'm taking on this issue for now and apply for GSoC with
> this issue in mind. I know that when it comes to GSoC, Apache will have to
> submit a list of possible projects for students to apply for. Is it possible
> that this is one of the possible projects? Or will I have to apply under
> "derby-testandfix"?
> In conversation with Kathey, I also considered another possibility, but for
> this I'd like some input from the community. This year I'm doing a Master's
> degree in Advanced Software Engineering, and I thought that perhaps it would
> be possible to take a Derby project as my Master's thesis. My department
> allows me to submit my own idea, but what I would like to know is if there
> is any outstanding, cutting-edge feature that we could possibly integrate
> into Derby, even if just in an experimental basis.
> On my course, there are two main focuses: service oriented architectures
> (web services and all aspects related to web service modelling) and model
> driven development (MDD). I'm not sure how familiar you are with the concept
> of MDD, as it does not seem to be something with a lot of hype surrounding
> it, but I think it could possibly be a good concept to apply to Derby. I've
> just been introduced this year to this concept and basically it boils down
> to generating code from models. So instead of writing Java code, we simply
> create a model and generate code from that; apparently this is being used in
> some companies and most of the times up to 90% of the code can be generated
> automatically. The remaining 10% are written by hand afterwards.
> This is just food for thought, if you know of any other issues/features that
> would make a good thesis subject, I'm open to suggestion.
> For now, however, I'll be taking on DERBY-728.
> Regards,
> Tiago Espinha
>
Re: Google Summer of Code
Posted by Ян Программист <we...@gmail.com>.
I think it is good to make a tool for displaying differences between two
hash index structs (before and after reindexing). Also graph of btree
entries with highlighting when debugging JOINs is awesome. John
2010/3/17 Rick Hillegas <Ri...@sun.com>
> Hi Denis,
>
> Many people seem to need a tool which produces a machine-readable or graph
> representation of the various phases of Derby's Abstract Syntax Trees. Some
> discussion of this topic can be found on DERBY-3946, DERBY-791, and
> DERBY-4415.
>
> It might also be interesting to make a tool out of the DatabaseMetaData
> functions/tableFunctions attached to DERBY-3973. Extra credit if this could
> be integrated with ij.
>
> I think these would be contained, safe projects for a GSoC student.
>
> Thanks,
> -Rick
>
> Denis Weerasiri wrote:
>
>> Hi devs,
>> Does anyone have more ideas related to derby tools?
>>
>> Cheers,
>> Denis
>>
>> On Sat, Mar 13, 2010 at 7:13 AM, Kathey Marsden <
>> kmarsdenderby@sbcglobal.net <ma...@sbcglobal.net>> wrote:
>>
>> Tiago Espinha wrote:
>>
>> Dear all,
>>
>> My name is Tiago Espinha and I participated in last year's
>> edition of Google Summer of Code. I've decided to participate
>> again this year
>>
>>
>> Welcome back and thanks for pulling DERBY-728 out of the freezer.
>> It is an often requested improvement. I put the labels
>> "mentor" and "gsoc" on the issue which is this year's process for
>> introducing it as a google summer of code idea. For GSOC you are
>> not limited to the ideas marked in Jira, but can introduce your
>> own idea as long as you find a mentor willing to pick it up.
>>
>> I have always been a bit skeptical of code generation tools. It
>> has been well over a decade since I have even looked at one, but
>> my experience was that while great for prototyping, they just did
>> not produce maintainable or properly commented code and were not
>> practical when working on a mature existing code base like Derby,
>> but am willing to be proven wrong.
>>
>> As for something meaty for your thesis, DERBY-472 Full text
>> indexing and search is forever popular. DERBY-11 is a more SQL
>> focussed project but should be a challenge. DERBY-672 user
>> defined aggregates might be interesting too, but I don't know how
>> much work it is exactly. I think there may be some pending XML
>> work too. Unfortunately though I can't step forward as a mentor
>> on any of these and hope you will work on DERBY-728 this summer
>> and start on a feature of some sort in the fall.
>>
>>
>> Kathey
>>
>>
>>
>
Re: Google Summer of Code
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Denis,
Many people seem to need a tool which produces a machine-readable or
graph representation of the various phases of Derby's Abstract Syntax
Trees. Some discussion of this topic can be found on DERBY-3946,
DERBY-791, and DERBY-4415.
It might also be interesting to make a tool out of the DatabaseMetaData
functions/tableFunctions attached to DERBY-3973. Extra credit if this
could be integrated with ij.
I think these would be contained, safe projects for a GSoC student.
Thanks,
-Rick
Denis Weerasiri wrote:
> Hi devs,
> Does anyone have more ideas related to derby tools?
>
> Cheers,
> Denis
>
> On Sat, Mar 13, 2010 at 7:13 AM, Kathey Marsden
> <kmarsdenderby@sbcglobal.net <ma...@sbcglobal.net>> wrote:
>
> Tiago Espinha wrote:
>
> Dear all,
>
> My name is Tiago Espinha and I participated in last year's
> edition of Google Summer of Code. I've decided to participate
> again this year
>
>
> Welcome back and thanks for pulling DERBY-728 out of the freezer.
> It is an often requested improvement. I put the labels
> "mentor" and "gsoc" on the issue which is this year's process for
> introducing it as a google summer of code idea. For GSOC you are
> not limited to the ideas marked in Jira, but can introduce your
> own idea as long as you find a mentor willing to pick it up.
>
> I have always been a bit skeptical of code generation tools. It
> has been well over a decade since I have even looked at one, but
> my experience was that while great for prototyping, they just did
> not produce maintainable or properly commented code and were not
> practical when working on a mature existing code base like Derby,
> but am willing to be proven wrong.
>
> As for something meaty for your thesis, DERBY-472 Full text
> indexing and search is forever popular. DERBY-11 is a more SQL
> focussed project but should be a challenge. DERBY-672 user
> defined aggregates might be interesting too, but I don't know how
> much work it is exactly. I think there may be some pending XML
> work too. Unfortunately though I can't step forward as a mentor
> on any of these and hope you will work on DERBY-728 this summer
> and start on a feature of some sort in the fall.
>
>
> Kathey
>
>
Re: Google Summer of Code
Posted by Bryan Pendleton <bp...@gmail.com>.
Denis Weerasiri wrote:
> I am Denis Weerasiri, a final year student from University of Moratuwa,
> Sri Lanka. I am hoping to participate in *GSOC* 2010 program. This would
> be my second *GSOC*. Last year I worked in and successfully completed
> Apache ODE project titled "Web-based BPEL debugger for Apache ODE". [1]
>
> I would be willing to work on Apache Derby project, under derby tooling
> this year if you are planning put any ideas forward. I have experience
> on developing applications in databases, data mining[2] etc.
> For last two weeks I went through some architecture and user
> documentations and submitted few patches as well.
> So are there any project ideas being considered as yet for Derby tooling
> this year?
Hi Denis,
I think it would be great to see some work in the area of tools for helping
with the analysis of complex query execution. Quite frequently, users of
Derby have trouble comprehending (a) how their query is being translated
into a query plan by the optimizer, and (b) what the execution-time resource
usage of the various parts of the query is.
There are low-level features in Derby which capture this information and
record it, such as logQueryPlan, and the XPLAIN tables, but there is a lot
of opportunity for designing higher-level tools which can process the query
plan and execution statistics information and present it in a more
comprehensible fashion.
thanks,
bryan
Re: Google Summer of Code
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Denis Weerasiri <dd...@gmail.com> writes:
> Yes, That would be really helpful to know the status of this SQL
> authorization support project.
Most of the functionality is in place, but there is a fair amount for
work to produce tests for this feature. Since there are no tests for
the new featuress yet, I would expects that some bugs in the
functionality are still present as well, so in all it might be enough
for a GSoC project to get this up to production quality.
Dag
Re: Google Summer of Code
Posted by Denis Weerasiri <dd...@gmail.com>.
On Wed, Mar 17, 2010 at 10:08 PM, Kathey Marsden <
kmarsdenderby@sbcglobal.net> wrote:
> Denis Weerasiri wrote:
>
>> I am Denis Weerasiri, a final year student from University of Moratuwa,
>> Sri Lanka. I am hoping to participate in *GSOC* 2010 program. This would be
>> my second *GSOC*. Last year I worked in and successfully completed Apache
>> ODE project titled "Web-based BPEL debugger for Apache ODE". [1]
>>
>> I would be willing to work on Apache Derby project, under derby tooling
>> this year if you are planning put any ideas forward. I have experience on
>> developing applications in databases, data mining[2] etc.
>> For last two weeks I went through some architecture and user
>> documentations and submitted few patches as well.
>> So are there any project ideas being considered as yet for Derby tooling
>> this year?
>>
>> One project that I think was started by a student last year that would be
> good to finish would be SQL Authorization Support for dblook (DERBY-4272).
> I don't know though the status of that work though and whether there is
> enough left to make it into a summer's worth of work or if you would be able
> to find a mentor willing to mentor the project. Dag could probably provide
> an update.
>
Yes, That would be really helpful to know the status of this SQL
authorization support project.
Thanks.
Denis Weerasiri
Re: Google Summer of Code
Posted by Kathey Marsden <km...@sbcglobal.net>.
Denis Weerasiri wrote:
> I am Denis Weerasiri, a final year student from University of
> Moratuwa, Sri Lanka. I am hoping to participate in *GSOC* 2010
> program. This would be my second *GSOC*. Last year I worked in and
> successfully completed Apache ODE project titled "Web-based BPEL
> debugger for Apache ODE". [1]
>
> I would be willing to work on Apache Derby project, under derby
> tooling this year if you are planning put any ideas forward. I have
> experience on developing applications in databases, data mining[2] etc.
> For last two weeks I went through some architecture and user
> documentations and submitted few patches as well.
> So are there any project ideas being considered as yet for Derby
> tooling this year?
>
One project that I think was started by a student last year that would
be good to finish would be SQL Authorization Support for dblook
(DERBY-4272). I don't know though the status of that work though and
whether there is enough left to make it into a summer's worth of work or
if you would be able to find a mentor willing to mentor the project.
Dag could probably provide an update.
Re: Google Summer of Code
Posted by Denis Weerasiri <dd...@gmail.com>.
I am Denis Weerasiri, a final year student from University of Moratuwa, Sri
Lanka. I am hoping to participate in *GSOC* 2010 program. This would be my
second *GSOC*. Last year I worked in and successfully completed Apache ODE
project titled "Web-based BPEL debugger for Apache ODE". [1]
I would be willing to work on Apache Derby project, under derby tooling this
year if you are planning put any ideas forward. I have experience on
developing applications in databases, data mining[2] etc.
For last two weeks I went through some architecture and user documentations
and submitted few patches as well.
So are there any project ideas being considered as yet for Derby tooling
this year?
Best Regards
Denis Weerasiri
http://ddweerasiri.blogspot.com
[1] -
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/asf/t124021709857
[2] -
http://ddweerasiri.blogspot.com/2010/02/association-rule-mining-with-extended.html
On Wed, Mar 17, 2010 at 10:24 AM, Denis Weerasiri <dd...@gmail.com>wrote:
> Hi devs,
> Does anyone have more ideas related to derby tools?
>
> Cheers,
> Denis
>
>
> On Sat, Mar 13, 2010 at 7:13 AM, Kathey Marsden <
> kmarsdenderby@sbcglobal.net> wrote:
>
>> Tiago Espinha wrote:
>>
>>> Dear all,
>>>
>>> My name is Tiago Espinha and I participated in last year's edition of
>>> Google Summer of Code. I've decided to participate again this year
>>>
>>
>> Welcome back and thanks for pulling DERBY-728 out of the freezer. It is
>> an often requested improvement. I put the labels "mentor" and "gsoc" on
>> the issue which is this year's process for introducing it as a google
>> summer of code idea. For GSOC you are not limited to the ideas marked in
>> Jira, but can introduce your own idea as long as you find a mentor willing
>> to pick it up.
>>
>> I have always been a bit skeptical of code generation tools. It has been
>> well over a decade since I have even looked at one, but my experience was
>> that while great for prototyping, they just did not produce maintainable or
>> properly commented code and were not practical when working on a mature
>> existing code base like Derby, but am willing to be proven wrong.
>>
>> As for something meaty for your thesis, DERBY-472 Full text indexing and
>> search is forever popular. DERBY-11 is a more SQL focussed project but
>> should be a challenge. DERBY-672 user defined aggregates might be
>> interesting too, but I don't know how much work it is exactly. I think
>> there may be some pending XML work too. Unfortunately though I can't step
>> forward as a mentor on any of these and hope you will work on DERBY-728
>> this summer and start on a feature of some sort in the fall.
>>
>>
>> Kathey
>>
>>
>
Re: Google Summer of Code
Posted by Denis Weerasiri <dd...@gmail.com>.
Hi devs,
Does anyone have more ideas related to derby tools?
Cheers,
Denis
On Sat, Mar 13, 2010 at 7:13 AM, Kathey Marsden <kmarsdenderby@sbcglobal.net
> wrote:
> Tiago Espinha wrote:
>
>> Dear all,
>>
>> My name is Tiago Espinha and I participated in last year's edition of
>> Google Summer of Code. I've decided to participate again this year
>>
>
> Welcome back and thanks for pulling DERBY-728 out of the freezer. It is
> an often requested improvement. I put the labels "mentor" and "gsoc" on
> the issue which is this year's process for introducing it as a google
> summer of code idea. For GSOC you are not limited to the ideas marked in
> Jira, but can introduce your own idea as long as you find a mentor willing
> to pick it up.
>
> I have always been a bit skeptical of code generation tools. It has been
> well over a decade since I have even looked at one, but my experience was
> that while great for prototyping, they just did not produce maintainable or
> properly commented code and were not practical when working on a mature
> existing code base like Derby, but am willing to be proven wrong.
>
> As for something meaty for your thesis, DERBY-472 Full text indexing and
> search is forever popular. DERBY-11 is a more SQL focussed project but
> should be a challenge. DERBY-672 user defined aggregates might be
> interesting too, but I don't know how much work it is exactly. I think
> there may be some pending XML work too. Unfortunately though I can't step
> forward as a mentor on any of these and hope you will work on DERBY-728
> this summer and start on a feature of some sort in the fall.
>
>
> Kathey
>
>
Re: Google Summer of Code
Posted by Kathey Marsden <km...@sbcglobal.net>.
Tiago Espinha wrote:
> Dear all,
>
> My name is Tiago Espinha and I participated in last year's edition of
> Google Summer of Code. I've decided to participate again this year
Welcome back and thanks for pulling DERBY-728 out of the freezer. It
is an often requested improvement. I put the labels "mentor" and
"gsoc" on the issue which is this year's process for introducing it as
a google summer of code idea. For GSOC you are not limited to the ideas
marked in Jira, but can introduce your own idea as long as you find a
mentor willing to pick it up.
I have always been a bit skeptical of code generation tools. It has
been well over a decade since I have even looked at one, but my
experience was that while great for prototyping, they just did not
produce maintainable or properly commented code and were not practical
when working on a mature existing code base like Derby, but am willing
to be proven wrong.
As for something meaty for your thesis, DERBY-472 Full text indexing and
search is forever popular. DERBY-11 is a more SQL focussed project but
should be a challenge. DERBY-672 user defined aggregates might be
interesting too, but I don't know how much work it is exactly. I think
there may be some pending XML work too. Unfortunately though I can't
step forward as a mentor on any of these and hope you will work on
DERBY-728 this summer and start on a feature of some sort in the fall.
Kathey