Paul,

sorry my misunderstanding - just comments at the moment as I work
through the code.

Norman

On Jan 4, 2008 10:24 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Norman
>
> I only meant that the DB would store the BLOB in a separate file, not
> that it would automatically do diffs.
>
> I agree that we need to implement the diffs.
>
> Paul
>
>
> Norman Barker wrote:
> > Paul,
> >
> > I think if you are running a cluster then the sys admin will have
> > already considered this and perhaps implemented GFS so a filesystem is
> > available.
> >
> > Looking at the version table
> >
> > CREATE TABLE VERSIONS (
> >             AID INTEGER NOT NULL,
> >             VN INTEGER NOT NULL,
> >             CONTENT BLOB,
> >             AUTHOR VARCHAR (500),
> >             UPDATED_TIME TIMESTAMP,
> >             UNIQUE (AID,VN),
> >             FOREIGN KEY (AID) REFERENCES ARTIFACTS (AID));
> >
> > even if the DB implements diff I am not sure how this schemas takes
> > advantage of this.
> >
> > Not being deliberately argumentative here, but the whole geospatial
> > use case is based on imagery (large) and this just isn't stored in the
> > DB.
> >
> >
> > Norman
> >
> > On Jan 4, 2008 10:00 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> >> Norman
> >>
> >> We discussed the use of a separate store for the content. However, many
> >> databases (DB2, Oracle) implement this already. Also, there is then a
> >> significant problem in deployment. For example, if you have a cluster,
> >> you now have to have a clustered file system as well as database.
> >>
> >> I like the idea of doing diffs as a pluggable idea.
> >>
> >> Paul
> >>
> >>
> >> Norman Barker wrote:
> >>> Hi,
> >>>
> >>> again correct me if I am wrong since I am new to the code, but looking
> >>> at the database schema I see that the complete content of the resource
> >>> is being stored in the artifact table, and in the version table.
> >>>
> >>> Really I would prefer the content to be stored outside of the DB (and
> >>> this what I am putting into the ORM version) as use case for data is
> >>> large (potentially gigabytes per resource).  For the version table is
> >>> it on the road to support xdelta type diffs (as in Subversion).  I see
> >>> there is a library called JRCS which was in Apache Commons and is now
> >>> LGPL.
> >>>
> >>> I mention this since it isn't just applicable to the ORM version, and
> >>> does impact the scalability of the registry.
> >>>
> >>> Norman
> >>>
> >>> _______________________________________________
> >>> Registry-dev mailing list
> >>> [email protected]
> >>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
> >>>
> >> --
> >> Paul Fremantle
> >> Co-Founder and VP of Technical Sales, WSO2
> >> OASIS WS-RX TC Co-chair
> >>
> >> Office: +1 646 290 8050
> >> Cell: +44 798 447 4618
> >>
> >> blog: http://pzf.fremantle.org
> >> [EMAIL PROTECTED]
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> _______________________________________________
> >> Registry-dev mailing list
> >> [email protected]
> >> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
> >>
> >
> > _______________________________________________
> > Registry-dev mailing list
> > [email protected]
> > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
> >
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> Office: +1 646 290 8050
> Cell: +44 798 447 4618
>
> blog: http://pzf.fremantle.org
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> _______________________________________________
> Registry-dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>

_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

Reply via email to