Cool :)

pony.orm.core.DBSchemaError: Index for column 'file_id' already exists Note about which table would be great

Also I now try dropping every Index there is

sweet!

This error is from the database, we have no control on how it looks. If you turn on sql output by using sql_debug(True) you can see which sql command was executed last

Is just printing GET NEW CONNECTION RELEASE CONNECTION

ok, it is a bug that should be fixed in the next release...

Do you create index for file_id column manually, or it is the index that Pony generates automatically?

I tried to rename the StickerPack table to simply Pack in the database

After changing the python code accordinly

Do you create index for file_id column manually, or it is the index that Pony generates automatically?

I have no clue.

Do you create index for file_id column manually, or it is the index that Pony generates automatically?

ORM created a Primary key on (file_id, emoji) before, Tried to change that to file_id only

So, yes the current index on file_id is what I created

Maybe I should rollback a backup and wait for migrations.... ...

But than, I never rolled back a backup, so I'll try to get it running again

I think it may be an index for a foreign key column. The Sticker entity has file_id attribute as a primary key, and I can guess that StickerPack entity has some attribute which defined as Required(Sticker) or Optional(Sticker). For such a column there is a foreign key to sticker table, and it is recommended to create an index as well. So Pony creates such indexes automatically. The name of the index includes the table name and looks like idx_stickerpack_attrname. You need to drop such index, and Pony will create new index with name idx_pack_attrname

I removed any primary key form file_id in that database

I think that the error is not with primary key, but with additional indexes

Some index which belongs to former stickerpack table and starts with idx_stickerpack_

It should start with idx_pack_ now

You can rename Pack back to StickerPack until migrations isnot released and all should work again

Okey, I just dropped all Constraints and Indexes I clould find

Nope.

Did you see indexes with names started with idx_?

Did you see indexes with names started with idx_?

No. I PMed you my current schema dump. Not sure if it is save to release in the public.

that's pretty sweet

Finally fixed that database

Finally fixed that database

And @StickerTagBot as well as getstickers.me is up again. (I really need to add a static served replacement for downtime like that.)

Thanks for your support @akozlovsky !!!

Basically the problem was PrimaryKey() not allowing index=True

Time to do backup ;)

Time to do backup ;)

Yes.

But I have no idea how I would import that, so I just solved the issue instead :D

Did ponyorm only allow one large model.py files ? Or can we separate to few small files?

Yes, you can split it to many files

Yes, you can split it to many files

Can the model with relationship also ?

yes # models1.py db = Database() class X(db.Entity): a = Set("Y") # syntax1 b = Set(lambda: db.Z) # syntax 2 # models2.py from models1 import db class Y(db.Entity): c = Required("X") # models3.py from models1 import db class Z(db.Entity): d = Optional(lambda: db.X)

when writing queries you can do this from models1 import X select(x for x in X if ...) or that: from models1 import db select(x for x in db.X if ...)

If you split entities between several files, then you need to not forget to import all of that files

yeah so they all get mapped

yes

Also, sometimes it may be convenient to define entities inside a function: def define_entities(db): class Person(db.Entity): name = Required(str) db = Database() define_entities(db) db.bind(...) db.generate_mapping(...) with db_session: select(p for p in db.Person)

yes # models1.py db = Database() class X(db.Entity): a = Set("Y") # syntax1 b = Set(lambda: db.Z) # syntax 2 # models2.py from models1 import db class Y(db.Entity): c = Required("X") # models3.py from models1 import db class Z(db.Entity): d = Optional(lambda: db.X)

?

Well, you wrote trainings = orm.Set('Training'), but entity Training is not found :)

sorry

looks like i need coffee

The online editor's Cascade delete setting still is broken, False becomes True in the python code export.

(Video uploading)

The online editor's Cascade delete setting still is broken, False becomes True in the python code export.

Oops.. Thanks for reporting, will fix that

Apparently a != default check

Also still a bug:

If I edit a text field and click in the editor window, it is not safed

As you see, you have to click another field first, else it isn't stored.

Also still a bug:

fixed

fixed

The unfocus one, or the Cascade delete?

The online editor's Cascade delete setting still is broken, False becomes True in the python code export.

fixed

both

both, ok :D

pls confirm

Still missing size=64 for ints, and sql_default='NOW()' for datetimes

pls confirm

Do I just have to refresh the page?

Do I just have to refresh the page?

yep

focus ✅

cascade delete ? Both default (False) and False result in packs = Set('Pack'). Setting it to False should result in packs = Set('Pack', cascade_delete=False) ? Setting it to False should result in packs = Set('Pack') ✅

you're right

Hello!

class Molecule(db.Entity): _table_ = (schema, 'molecule') id = PrimaryKey(int, auto=True) date = Required(datetime, default=datetime.utcnow()) data = Required(Json) fear = Required(str, unique=True) fingerprint = Required(str, sql_type='bit(%s)' % (2 ** FP_SIZE)) children = Set('Molecule', cascade_delete=True) parent = Optional('Molecule')

is it possible delete parent relation without delete data?

e.g. return parent to None

Yes, why not: m = Molecule[id] m.parent = None

Thank You!

Sure

cascade delete ? Both default (False) and False result in packs = Set('Pack'). Setting it to False should result in packs = Set('Pack', cascade_delete=False) ? Setting it to False should result in packs = Set('Pack') ✅

how about now?

how about now?

The default now is true?

The default now is true?

Stange. There are some sets now with Default (True) and some with Default (False)

depending on the attribute type

if the other side is Required then default is True if the other side is Optional then default is False

Oh. Okey, that makes sense.

Is that reflected corretly on the python side?

should be

Huh, cool

Still missing size=64 for ints, and sql_default='NOW()' for datetimes

will add that soon

how about now?

And somehow dangerous, could be unexpected if the default differes...

how about now?

Works, yes.

✅

?