After thinking a bit more about it, could it be that the two tables are used for mapping ? I think that would make sense because we have a many relation here..
So one for mapping Message and Properties and one for Message and Header. Bye, Norman 2010/6/10 Eric Charles <[email protected]>: > Hi Norman, > > - I will also try to see what happens with the foreign keys. > - MESSAGE_PROPERTY and MESSAGE_HEADER are created today during a fresh > install. > - Yes, input from community is welcome for the primary key generation > strategy. Anyone? > - I now better understand JPAMessage streaming. Many tks for the > explanation. Will also look for derby (maybe with latest 1.6). > > Back to MailboxMembership, I was happy to see uid is part of the > MailboxMembership. It's good that a mail copy get a new UID. > > As Tim, I don't often copy mails: the "space" argument should not be > retained. > The memory argument is interesting for database that does not support > streaming. I'm just wondering when the mail is completely loaded: during > mail list when a client consults a server or only during attachment > download? > We should also stick to a common strategy for all stores (jcr, jpa,...). Is > JCR also working with a temporary structure linking Mailbox and Mail? > > Tks, > > Eric > > On 06/10/2010 11:09 AM, Norman Maurer wrote: >> >> Hi Eric, >> >> comments inside... >> >> 2010/6/9 Eric Charles<[email protected]>: >> >>> >>> Hi, >>> >>> A stable database schema would be great. >>> Upgrading jars is straightforward, but changing the db schema (and >>> potentially the datas) is always a pain. >>> >>> I had a look at the generated tables (see the list after the text). >>> All have primary key and unique constraints, but there are no foreign >>> keys >>> (no constraints integrity). >>> The buildSchema(ForeignKeys=ue) does not seem to create something for the >>> @ManyToOne. >>> Or maybe is this specific to derby (I'm using), and other databases such >>> as >>> mysql,... behave differently? >>> >> >> I need to check, I'm currently using JCR so no idea atm.. >> >>> >>> I also didn't find an entity for MESSAGE_PROPERTY nor MESSAGE_HEADER. >>> However the table exists. >>> >> >> Maybe somthing from the "good old days" ? does they get created on a >> fresh install ? >> >> >> >>> >>> As far I can understand, the primary keys are all generated via the >>> default >>> OPENJPA_SEQUENCE_TABLE. >>> I often let each the table auto_generate the primary keys >>> (strategy=nerationType.IDENTITY). Are there any plans for this in the >>> future, or will we remain with the unique default OPENJPA_SEQUENCE_TABLE? >>> >> >> I have no strong opinion here.. Anyone ? >> >> >>> >>> About MailboxMembership, Tim, you said the whole message is not loaded >>> tks >>> to streaming. >>> Right now, openjpa.streamingúlse in database.properties but when I look >>> JPAMessage implementation, it seems that the content is loaded via >>> InputStream. >>> So what is the current state? Should the openjpa.streaming property be >>> removed? >>> >>> >> >> Let me try to explain it.. When you have a look at JPAMessage you see >> it use a byte[] object to store the message content. So once you need >> to read the content, the whole content get loaded in memory. Thats the >> default and work for every db. If you use openjpa.streaming=ue it >> will stream the content direct from the db. So it never need to load >> the content into the memory at all. This only works for a few >> databases (derby is not one of them). Thats why it is false by >> default. >> >> >> >> >>> >>> Sorry for my "in-vrac" comments. Each of them may worth a separate >>> thread. >>> Tks, >>> >>> Eric >>> >>> MEMBERSHIP >>> JAMESUSER >>> MAILBOX >>> HEADER >>> MESSAGE >>> MESSAGE_HEADER >>> MESSAGE_PROPERTY >>> DOMAIN >>> SUBSCRIPTION >>> PROPERTY >>> BAYESIANANALYSIS_SPAM >>> VIRTUALUSERTABLE >>> BAYESIANANALYSIS_MESSAGECOUNTS >>> BAYESIANANALYSIS_HAM >>> OPENJPA_SEQUENCE_TABLE >>> >>> On 06/09/2010 10:18 AM, Norman Maurer wrote: >>> >>>> >>>> Right, >>>> >>>> I think we should at least be sure to not change the layout anymore. I >>>> don't have a strong opinion on the double storage vs. single storage. >>>> If we don't need the single storage we could just "merge" Document and >>>> MailboxMembership interface. >>>> >>>> Bye, >>>> Norman >>>> >>>> >>>> 2010/6/9 Tim-Christian Mundt<[email protected]>: >>>> >>>> >>>>> >>>>> Hi! >>>>> >>>>> There is this one change of the database layout which should be decided >>>>> upon >>>>> before releasing, I think. Messing with code after the release is fine, >>>>> but >>>>> changing the database would be bad. I'm talking about Normans idea to >>>>> unite >>>>> the Message and Membership interfaces/classes = tables. The original >>>>> idea >>>>> of separating those was not to pass the whole mime message around when >>>>> just >>>>> the flags are needed. Moreover, the Membership part would serve as a >>>>> reference to the Message so that a copy would just mean another >>>>> reference >>>>> to >>>>> the same mail. >>>>> >>>>> The question: does the increased complexity really pay off? I think >>>>> saving >>>>> space is not really an argument because it's not really common to have >>>>> duplicates (at least in my experience). And loading the "whole message" >>>>> would not mean the contents but only a stream handler, not a memory >>>>> killer, >>>>> right? >>>>> >>>>> Regards >>>>> Tim >>>>> >>>>> Eric Charles: >>>>> >>>>> >>>>>> >>>>>> Running here without any problem jpa (embedded derby) + jdbc >>>>>> domainlist >>>>>> + >>>>>> spamassassin + forwarding mailet. >>>>>> When do you think to release? >>>>>> Tks, >>>>>> Eric >>>>>> >>>>>> On 06/07/2010 04:51 PM, Norman Maurer wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Thx mate.. >>>>>>> >>>>>>> I deployed fresh trunk and everything seems to work so far without >>>>>>> problems :) >>>>>>> >>>>>>> Bye, >>>>>>> Norman >>>>>>> >>>>>>> Ps: I'm using JCR Mailbox >>>>>>> >>>>>>> 2010/6/7 Eric Charles<[email protected]>: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> I will deploy a fresh trunk this night just to make sure everything >>>>>>>> is >>>>>>>> still >>>>>>>> ok (cfr last commits in protocol,..). >>>>>>>> The last snapshot I took is 2 weeks-old and is really stable. >>>>>>>> >>>>>>>> Tks, >>>>>>>> Eric >>>>>>>> >>>>>>>> >>>>>>>> On 06/07/2010 04:40 PM, Norman Maurer wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I think all the stuff in the imap library is now very usable. I >>>>>>>>> think >>>>>>>>> we should cut a milestone and then cut one of james server. >>>>>>>>> Anything >>>>>>>>> you guys want to get refactored before ? >>>>>>>>> >>>>>>>>> Bye, >>>>>>>>> Norman >>>>>>>>> >>>>>>>>> Ps: Even if we discover a bug later we can cut just another one.. >>>>>>>>> Release often, Release early (urgh...) >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> Bye, >> Norman >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
