Skip to content

Releases: latolukasz/beeorm

Small fixes

01 Oct 06:13
Compare
Choose a tag to compare
v1.2.1

better validations

Removed speed stats from event consumer

27 Sep 12:22
Compare
Choose a tag to compare
v1.2.0

removed speed stats frome event broker

fixed redis search alters

24 Sep 22:54
Compare
Choose a tag to compare
v1.1.6

fixed redis search alters

disableCacheHashCheck in yaml

24 Sep 12:58
Compare
Choose a tag to compare

now you can add in yaml:

default:
  disableCacheHashCheck: true

DisableCacheHashCheck

24 Sep 10:58
Compare
Choose a tag to compare

now you can disable cache hash check with:

beeorm.DisableCacheHashCheck()

Fixed on duplicate key with dates

23 Sep 12:46
Compare
Choose a tag to compare
v1.1.3

fixed date in duplikate key update

Entity structure cache stamp

23 Sep 11:49
Compare
Choose a tag to compare

Now if two applications are using different entity structure BeeORM will throw panic

static redis keys for entity

22 Sep 13:06
Compare
Choose a tag to compare

Before BeeORM was using entity structure to generate redis key. So when entity structure was changed, for example,
new column was added after deploy all entity redis keys were different. Now BeeORM uses only entity full name to calculate redis key hash.

Imagine this scenario - two applications are using the same entity - UserEtity. The developer added new column to this entity and deployed code on applications #1 and #2. All worked as expected, new redis keys are used so all queries with this Entity loaded data from Mysql and filled redis cache. Is not required to clear redis after deploy.

But now imagine developer deployed code only in application #1 but forgot to deploy it in application #2 (it happened today for instance in one of the projects). Then i application #1 all keys are invalid ad cache is filled with new data but inapplication #2 uses still all keys. So changes in one application are not visible and applications are broken.

Solution is to always deploy applications that the same entities at the same time or simply switch to this version of BeeORM.
In this version reids key is build based on enity name. So even if you forgot to deploy code in in applications #2 damage is much smaller. data is updated in both applications in cache but you will start seeing new type of errors, for example applications #2 is getting data from cache with new column and can't unserialize it. But it's better to do it this way, less evil.

Redis keys namespace

22 Sep 09:16
Compare
Choose a tag to compare

https://beeorm.io/guide/data_pools.html#redis-keys-namespace

Now you can define a keys namespace for in every redis or redis sentinel pool:

before:

registry.RegisterRedis("localhost:6379", 0)

now:

registry.RegisterRedis("localhost:6379",  "", 0) //added required second argument, use empty string ("") to use empty keyspace

So if you want to use one redis server and one DB for many applications simply define different namespaces:

app #1
registry.RegisterRedis("localhost:6379", "app1" 0)
app #2
registry.RegisterRedis("localhost:6379", "app2" 0)

in yaml files key namespace is optional, you should add it after DB umber (if needed):

default:
  sentinel:
    master:0:my_namespace:
    
another_pool:
  redis: localhost:6382:1:test_namespace    

removed stopwords from entity redis search index

16 Sep 12:41
Compare
Choose a tag to compare
v1.0.43

removed stopwords from entity redis search index