You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gerhard Froehlich <g-...@gmx.de> on 2002/02/11 18:11:34 UTC
[simplestore] ToDo
Juozas,
JB>TODO for sample :
JB>1. Add OIDGenerator interface and default impl.
JB>OID interface to generate a unique ObjectID. The
JB>implementation can be Random, Auto-Increment, s.o.
Ahh ok now I understand ;-). Maybe something I can
pick up.
JB>2. Add a mapping interface and a default impl of "MetaClass".
JB>I will implement this. Default will be "by method name",
JB>we can add XML descriptors later.
Kool
JB>3. Add relations. The same as for 2. validators. To
JB>abort transactions and report errors, if some value
JB>is invalid. This is also class metadata.
This I don't understand...
JB>4. Remove method "convert" from Proxy, add a converter
JB>interface and a default impl. Separate "converter" and
JB>"object state"! Also "MetaObject" is not a very good name.
JB>Better would be something like "PersistentObjectState" (vs.
JB>"StateManager in JDO").
Ok that shouldn't be that problem.
JB>5. Add PersitenceManager and PersitenceManagerFactory
JB>interfaces and default impl. This is trivial.
Oh nice something for me ;-)
JB>6. Implement a rollback method for SoftRefMemoryStore
JB>in TransactionImpl. Not tested yet, but it's trivial
JB>just clone and copy.
Ok, your words in gods ear.
JB>7. Add synchronization of transaction (Listeners) methods
JB>and transaction state Constants to the Transaction
JB>interface. No implementation so far only interface definitions
JB>like in JTA.
Ok. You're the expert here.
JB>8. Make Proxy more abstract, to add interceptors for security and
JB>distributed objects. Trivial, add a parameter "List of interceptors".
JB>Interceptor implements "InvocationHandler".
Aha.
JB>9. Finders (I have no good ideas about finders at this time), but no SQL.
JB>Some procedure name at this time.
What do you exactly mean with finders. Find objects?
JB>10. Add suport for class instances (ByteCode generation and "*.class"
JB>transformations). I think this is optional.
Ohh BCEL would be an option, but the community their sucks. Zero traffic in
the mailing list. You don't get any help from that dudes. Am I right Paul ;).
JB>11. Some limited implementation for JDO interfaces, because this is very
JB>close to JDO.
Sama as #7
GF>Ok much stuff...could we split this a little bit, like first this, second
GF>that?
GF>1. cleanup code
GF> This is 98% done so far.
99% ;)
GF> 2. move this stuff maybe in a seperate package, like
GF> org.apache.commons.simplestore.cache
GF> org.apache.commons.simplestore.persistence
GF> org.apache.commons.simplestore.persistence.jdbc
GF> org.apache.commons.simplestore.persistence. ...
GF>
GF> This implies, that org.apache.commons.simplestore.persistence is very
GF> generic and the sub-packages are more specific impl for that.
GF>
GF> 3. starting with your points.
GF> maybe first with #5, #4, #2 and #8
>Ok.
Ok then I'll move this sample stuff "as is" in to the
main package!
interfaces under:
<org.apache.commons.simplestore.persistence>
and implementation (maybe with Defaultxxx.class) under:
<org.apache.commons.simplestore.persistence.impl>
Or should give them some more meaningful name as impl?
Where should we put this JDBC stuff?
Same for the cache, of course!
BTW: Could please adapt the Jakarta coding style. Just look
in the other projects how they format code. I now that's
a PITA but necessary. TIA.
~Gerhard
"Anything awful makes me laugh.
I misbehaved once at a funeral..."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] ToDo
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
>> >> JB>10. Add suport for class instances (ByteCode generation and
>"*.class"
>> >> JB>transformations). I think this is optional.
>> >>
>> >> Ohh BCEL would be an option, but the community their sucks. Zero
>traffic
>> >in
>> >> the mailing list. You don't get any help from that dudes. Am I right
>Paul
>> >
>> >;).
>> >I have this code and I think it is very good and clear, but I think it is
>> >beter to generate some ASM for java and compile it in memory.
>>
>> Is this code written in BCEL?
>> ASM?
>
> I saw a few ASM for java implementations, one of them use BCEL to implement
>this stuff,
>I don't remember, but I think it is JASMIN.
>I have plans to generate byte code this way : Template -> ASM -> Byte Code
We tried BCEL in the AvalonDB project, but didn't suceed (less documentation
and low traffic in the mailing list). Complex beast.
Jasmin I don't know...but Paul seems to have expierience...
>
>> >We will need pool for arrays, I dont know trivial and good
>implementation,
>> >but it is very trivial to implement (the Same as "Swap" and "Reacheble")
>>
>> Aha, for what do we need this pool?
>
>This pool will be for List, Map and Set, very trivial wrapper will return
>object to pool
>on finalization.
Ok.
>> >I don have ideas abaut this :) Datasource implementation is incorrect,
>but
>> >it has good performance on PostgreSQL, because driver implements pool
>> >itself .... .
>>
>> It has now his own package, and people can use it if they want. But maybe
>> we should remove this PostgreSQL javadoc, because it works for hsqldb too
>;).
>We will remove this Datasource itself later, it is good for some
>applications and works
>with most of drivers in "readonly" mode, but it will not work on simplestore
>if
>transactionCount > maxConectionCount, but it can be used for testing, don't
>use it in production if data is not "readonly", you will have fatal errors
>in transactions.
Yep...
I hope I will find some time on the weekend. I booked in a trivial OID generator.
Check it out...
~Gerhard
"The most important question when any new
computer architecture is introduced is 'So what?'"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] ToDo
Posted by Juozas Baliuka <ba...@mwm.lt>.
> >> JB>10. Add suport for class instances (ByteCode generation and
"*.class"
> >> JB>transformations). I think this is optional.
> >>
> >> Ohh BCEL would be an option, but the community their sucks. Zero
traffic
> >in
> >> the mailing list. You don't get any help from that dudes. Am I right
Paul
> >
> >;).
> >I have this code and I think it is very good and clear, but I think it is
> >beter to generate some ASM for java and compile it in memory.
>
> Is this code written in BCEL?
> ASM?
I saw a few ASM for java implementations, one of them use BCEL to implement
this stuff,
I don't remember, but I think it is JASMIN.
I have plans to generate byte code this way : Template -> ASM -> Byte Code
> >We will need pool for arrays, I dont know trivial and good
implementation,
> >but it is very trivial to implement (the Same as "Swap" and "Reacheble")
>
> Aha, for what do we need this pool?
This pool will be for List, Map and Set, very trivial wrapper will return
object to pool
on finalization.
> >I don have ideas abaut this :) Datasource implementation is incorrect,
but
> >it has good performance on PostgreSQL, because driver implements pool
> >itself .... .
>
> It has now his own package, and people can use it if they want. But maybe
> we should remove this PostgreSQL javadoc, because it works for hsqldb too
;).
We will remove this Datasource itself later, it is good for some
applications and works
with most of drivers in "readonly" mode, but it will not work on simplestore
if
transactionCount > maxConectionCount, but it can be used for testing, don't
use it in production if data is not "readonly", you will have fatal errors
in transactions.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] ToDo
Posted by Gerhard Froehlich <g-...@gmx.de>.
Juozas,
<skip/>
>> JB>8. Make Proxy more abstract, to add interceptors for security and
>> JB>distributed objects. Trivial, add a parameter "List of interceptors".
>> JB>Interceptor implements "InvocationHandler".
>
> we will add then to metadata
Ok (Not that 100% clear, but I will throw a look on this).
>>
>> Aha.
>>
>> JB>9. Finders (I have no good ideas about finders at this time), but no
>> JB>SQL. Some procedure name at this time.
>>
>> What do you exactly mean with finders. Find objects?
>>
>> JB>10. Add suport for class instances (ByteCode generation and "*.class"
>> JB>transformations). I think this is optional.
>>
>> Ohh BCEL would be an option, but the community their sucks. Zero traffic
>in
>> the mailing list. You don't get any help from that dudes. Am I right Paul
>
>;).
>I have this code and I think it is very good and clear, but I think it is
>beter to generate some ASM for java and compile it in memory.
Is this code written in BCEL?
ASM?
>> JB>11. Some limited implementation for JDO interfaces, because this is
>> JB>veryclose to JDO.
>>
>> Sama as #7
>>
>> GF>Ok much stuff...could we split this a little bit, like first this, second
>> GF>that?
>> GF>1. cleanup code
>> GF> This is 98% done so far.
>>
>> 99% ;)
>>
>> GF> 2. move this stuff maybe in a seperate package, like
>> GF> org.apache.commons.simplestore.cache
>> GF> org.apache.commons.simplestore.persistence
>> GF> org.apache.commons.simplestore.persistence.jdbc
>> GF> org.apache.commons.simplestore.persistence. ...
>
>We will need pool for arrays, I dont know trivial and good implementation,
>but it is very trivial to implement (the Same as "Swap" and "Reacheble")
Aha, for what do we need this pool?
>> GF>
>> GF> This implies, that org.apache.commons.simplestore.persistence is very
>> GF> generic and the sub-packages are more specific impl for that.
>> GF>
>> GF> 3. starting with your points.
>> GF> maybe first with #5, #4, #2 and #8
>>
>> >Ok.
>>
>> Ok then I'll move this sample stuff "as is" in to the
>> main package!
>
>Yes, this sample become too mutch advanced for demo.
Done as you seen.
>> interfaces under:
>> <org.apache.commons.simplestore.persistence>
>> and implementation (maybe with Defaultxxx.class) under:
>> <org.apache.commons.simplestore.persistence.impl>
>> Or should give them some more meaningful name as impl?
>>
>> Where should we put this JDBC stuff?
>> Same for the cache, of course!
>
>I don have ideas abaut this :) Datasource implementation is incorrect, but
>it has good performance on PostgreSQL, because driver implements pool
>itself .... .
It has now his own package, and people can use it if they want. But maybe
we should remove this PostgreSQL javadoc, because it works for hsqldb too ;).
>>
>> BTW: Could please adapt the Jakarta coding style. Just look
>> in the other projects how they format code. I now that's
>> a PITA but necessary. TIA.
>
>Ok, I will try ( I use NetBeans formater, but I know there are more command
>line "Auto Formaters" in SourceForge )
Did you try jedit? www.jedit.org. Very kool editor! Check out the plugins!
~Gerhard
"When I die, I want to go just like my Grandfather,
in my sleep.
Not like the screaming passengers in the car
he was driving."
(Ancient Chinese Proverb)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] ToDo
Posted by Juozas Baliuka <ba...@mwm.lt>.
> Juozas,
>
> JB>TODO for sample :
> JB>1. Add OIDGenerator interface and default impl.
> JB>OID interface to generate a unique ObjectID. The
> JB>implementation can be Random, Auto-Increment, s.o.
>
> Ahh ok now I understand ;-). Maybe something I can
> pick up.
>
> JB>2. Add a mapping interface and a default impl of "MetaClass".
> JB>I will implement this. Default will be "by method name",
> JB>we can add XML descriptors later.
>
> Kool
>
> JB>3. Add relations. The same as for 2. validators. To
> JB>abort transactions and report errors, if some value
> JB>is invalid. This is also class metadata.
>
> This I don't understand...
>
> JB>4. Remove method "convert" from Proxy, add a converter
> JB>interface and a default impl. Separate "converter" and
> JB>"object state"! Also "MetaObject" is not a very good name.
> JB>Better would be something like "PersistentObjectState" (vs.
> JB>"StateManager in JDO").
>
> Ok that shouldn't be that problem.
>
> JB>5. Add PersitenceManager and PersitenceManagerFactory
> JB>interfaces and default impl. This is trivial.
>
> Oh nice something for me ;-)
>
> JB>6. Implement a rollback method for SoftRefMemoryStore
> JB>in TransactionImpl. Not tested yet, but it's trivial
> JB>just clone and copy.
>
> Ok, your words in gods ear.
>
> JB>7. Add synchronization of transaction (Listeners) methods
> JB>and transaction state Constants to the Transaction
> JB>interface. No implementation so far only interface definitions
> JB>like in JTA.
>
> Ok. You're the expert here.
>
> JB>8. Make Proxy more abstract, to add interceptors for security and
> JB>distributed objects. Trivial, add a parameter "List of interceptors".
> JB>Interceptor implements "InvocationHandler".
we will add then to metadata
>
> Aha.
>
> JB>9. Finders (I have no good ideas about finders at this time), but no
SQL.
> JB>Some procedure name at this time.
>
> What do you exactly mean with finders. Find objects?
>
> JB>10. Add suport for class instances (ByteCode generation and "*.class"
> JB>transformations). I think this is optional.
>
> Ohh BCEL would be an option, but the community their sucks. Zero traffic
in
> the mailing list. You don't get any help from that dudes. Am I right Paul
;).
I have this code and I think it is very good and clear, but I think it is
beter to generate some
ASM for java and compile it in memory.
>
> JB>11. Some limited implementation for JDO interfaces, because this is
very
> JB>close to JDO.
>
> Sama as #7
>
> GF>Ok much stuff...could we split this a little bit, like first this,
second
> GF>that?
> GF>1. cleanup code
> GF> This is 98% done so far.
>
> 99% ;)
>
> GF> 2. move this stuff maybe in a seperate package, like
> GF> org.apache.commons.simplestore.cache
> GF> org.apache.commons.simplestore.persistence
> GF> org.apache.commons.simplestore.persistence.jdbc
> GF> org.apache.commons.simplestore.persistence. ...
We will need pool for arrays, I dont know trivial and good implementation,
but
it is very trivial to implement (the Same as "Swap" and "Reacheble")
> GF>
> GF> This implies, that org.apache.commons.simplestore.persistence is very
> GF> generic and the sub-packages are more specific impl for that.
> GF>
> GF> 3. starting with your points.
> GF> maybe first with #5, #4, #2 and #8
>
> >Ok.
>
> Ok then I'll move this sample stuff "as is" in to the
> main package!
Yes, this sample become too mutch advanced for demo.
> interfaces under:
> <org.apache.commons.simplestore.persistence>
> and implementation (maybe with Defaultxxx.class) under:
> <org.apache.commons.simplestore.persistence.impl>
> Or should give them some more meaningful name as impl?
>
> Where should we put this JDBC stuff?
> Same for the cache, of course!
I don have ideas abaut this :) Datasource implementation is incorrect, but
it has good performance on PostgreSQL, because driver implements pool
itself .... .
>
> BTW: Could please adapt the Jakarta coding style. Just look
> in the other projects how they format code. I now that's
> a PITA but necessary. TIA.
Ok, I will try ( I use NetBeans formater, but I know there are more command
line "Auto Formaters" in SourceForge )
> ~Gerhard
>
> "Anything awful makes me laugh.
> I misbehaved once at a funeral..."
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] ToDo
Posted by Gerhard Froehlich <g-...@gmx.de>.
Juozas,
>Ok, I will join on weekend
Easy, it was just a joke because
I replied on my own quotings. A
litte bit schizophrenic ;).
~Gerhard
----------------------------
You can't fall off the floor
----------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [simplestore] ToDo
Posted by Juozas Baliuka <ba...@mwm.lt>.
Ok, I will join on weekend
> Hi,
>
> Gerhard is talking with himself:
>
> >GF>Ok much stuff...could we split this a little bit, like first this,
second
> >GF>that?
> >GF>1. cleanup code
> >GF> This is 98% done so far.
> >
> >99% ;)
> >
> >GF> 2. move this stuff maybe in a seperate package, like
> >GF> org.apache.commons.simplestore.cache
> >GF> org.apache.commons.simplestore.persistence
> >GF> org.apache.commons.simplestore.persistence.jdbc
> >GF> org.apache.commons.simplestore.persistence. ...
> >GF>
> >GF> This implies, that org.apache.commons.simplestore.persistence is very
> >GF> generic and the sub-packages are more specific impl for that.
> >GF>
> >GF> 3. starting with your points.
> >GF> maybe first with #5, #4, #2 and #8
> >
> >>Ok.
> >
> >Ok then I'll move this sample stuff "as is" in to the
> >main package!
> >interfaces under:
> > <org.apache.commons.simplestore.persistence>
> >and implementation (maybe with Defaultxxx.class) under:
> > <org.apache.commons.simplestore.persistence.impl>
> >Or should give them some more meaningful name as impl?
> >
> >Where should we put this JDBC stuff?
> >Same for the cache, of course!
>
> That part is done now!
>
> >BTW: Could please adapt the Jakarta coding style. Just look
> >in the other projects how they format code. I now that's
> >a PITA but necessary. TIA.
>
> Still a little issue!
>
> > ~Gerhard
>
> ---------------------------------------------------
> Okay, who put a "stop payment" on my reality check?
> ---------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [simplestore] ToDo
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
Gerhard is talking with himself:
>GF>Ok much stuff...could we split this a little bit, like first this, second
>GF>that?
>GF>1. cleanup code
>GF> This is 98% done so far.
>
>99% ;)
>
>GF> 2. move this stuff maybe in a seperate package, like
>GF> org.apache.commons.simplestore.cache
>GF> org.apache.commons.simplestore.persistence
>GF> org.apache.commons.simplestore.persistence.jdbc
>GF> org.apache.commons.simplestore.persistence. ...
>GF>
>GF> This implies, that org.apache.commons.simplestore.persistence is very
>GF> generic and the sub-packages are more specific impl for that.
>GF>
>GF> 3. starting with your points.
>GF> maybe first with #5, #4, #2 and #8
>
>>Ok.
>
>Ok then I'll move this sample stuff "as is" in to the
>main package!
>interfaces under:
> <org.apache.commons.simplestore.persistence>
>and implementation (maybe with Defaultxxx.class) under:
> <org.apache.commons.simplestore.persistence.impl>
>Or should give them some more meaningful name as impl?
>
>Where should we put this JDBC stuff?
>Same for the cache, of course!
That part is done now!
>BTW: Could please adapt the Jakarta coding style. Just look
>in the other projects how they format code. I now that's
>a PITA but necessary. TIA.
Still a little issue!
> ~Gerhard
---------------------------------------------------
Okay, who put a "stop payment" on my reality check?
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>