#1 Re: mORMot 1 » Bug Report UTF8 » 2019-12-04 19:48:15

Standard English install,  no code page changes. I am not sure how to check the one it is using.
Language setting is ENG US keyboard.

I found the code page, 437. I dont change it.

#2 mORMot 1 » Bug Report UTF8 » 2019-12-04 03:31:00

MichaelR
Replies: 3

I have a few errors running the mORMot test project off a fresh download.

The first failing test output is


!  - TRawUTF8Interning: 2 / 2,000,013 FAILED  27.84s
     500000 interning 8 KB in 36.89ms i.e. 13,552,339/s, aver. 0us, 206.7 MB/s
     500000 direct 7.6 MB in 10.82ms i.e. 46,180,844/s, aver. 0us, 704.6 MB/s
The second failing situation is due to timeout with a break point that I cant seem to clear. I screen grabbed it, but this forum doesnt support images. Email me if you want it.

I am running Windows 10 on a laptop.

Delphi XE3.

I added the paths as directed for both 32 and 64 bit. This is a 32 bit debug build

I should add that I did register TestSql3Register project

Thanks

#3 Re: mORMot 1 » Save huge file-stream (considered about 2GB) in a Table as BLOB. » 2014-06-09 06:12:22

For big data blobs it always matters how it needs to be accessed later. Files like yours are either not important, or they are full of redundancy that has been ignored, or they are files like video that never belongs in a database ever anywhere.

If you are corporate and need lots and lots of big docs like this for some reason I would check out a full scale document management package like Alfresco. Do you need to access parts of this thing sometimes? Break it up. Do you have a document centric publish model going here with incremental changes? Publish each segment independently and use document references not copy/paste redundancy. Proper records management and publishing model is probably way over due. Capture the delta. If you know DDD then go look for the value objects.

Yes I know what it costs. Mostly it costs managers their brain power. Mostly it makes stupid people look stupid when you start designing this way. Sorry for their stupidity. You have put up with a lot for a long time. Now it is time to make stupid hard to do.

#4 Re: mORMot 1 » trees structure » 2014-01-24 19:58:54

2 contra - limited level of tree depth (max is varchar (4000) = newar 15 levels ) and hard to update parentID in case element have child.

I like this style too, but your limits are not absolute.

The first / is redundant and can be eliminated. Most tree data has a variety of object types linked to it and I often use punctuation differences to indicate which type a link has. (especially useful for filtering, not every type needs its own punctuation, just groups) A further refinement is to use an encoding 0-9A-Za-z for the integer keys giving a significant reduction in size because the numbers are recorded in base 62, and hence a deeper tree. In practice if you insist on lower layered ids having small values then you can go even deeper bc you know that highly repeating values are short.

It would also be great to extend this to allow a pre-defined security filter set such that you could link it up for fast user/ role based access from a particular node down. I have done this a few times. It is similar to Active Directory in practice and it works quite well. Actually linking it to AD is another matter.

Board footer

Powered by FluxBB