Skip to content

support for V ORM#198

Open
daniel-le97 wants to merge 13 commits intoelliotchance:mainfrom
daniel-le97:vsql-orm-integration
Open

support for V ORM#198
daniel-le97 wants to merge 13 commits intoelliotchance:mainfrom
daniel-le97:vsql-orm-integration

Conversation

@daniel-le97
Copy link
Copy Markdown

Now that V ORM allows mutable Connections via vlang/v#22684,
integration of the ORM does not require major workarounds or creating separate DB connections

Example usage

module main

import vsql

struct Product {
	id           int
	product_name string
	price        f64
}

fn main() {
	mut db := vsql.open('test.vsql')!

	sql db {
		create table Product
	}!
}

Tests

Tests can be run by either of the following

v -stats test ./vsql/orm_test.v

or

make orm-test

This implementation does take code/ideas from the initial work done on this in #102

It also implements most of the same test done in the original work.

The only change i see is that in this implementation, @[primary] attributes are also not supported as they will break delete queries. This can easily be changed tho.

Not Supported

  • enums for field values
  • default attribute
  • unique attribute
  • primary attribute

fixes #90

sql-test: oldv
$(V) -stats $(BUILD_OPTIONS) vsql/sql_test.v

orm-test: oldv
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just adding a note here for me to add this to the docs.

@daniel-le97
Copy link
Copy Markdown
Author

Sorry for not cleaning this up, i have now removed comments/ commented code that do not add context

@elliotchance
Copy link
Copy Markdown
Owner

I fixed the docs CI job and ran v fmt in #201, so please rebase.

Also, can you add a section to https://github.com/elliotchance/vsql/blob/main/docs/testing.rst#test-suites to add orm-test as its own suite.

example() or { panic(err) }
}

// NOTE for some reason if we declare a @[primary] on a struct field, we can not do delete queries on the tables...
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now fixed: #203

@elliotchance
Copy link
Copy Markdown
Owner

@daniel-le97 any update on this? You can avoid the rebase entirely and just put the new files, it would look like this: #209

elliotchance and others added 8 commits March 5, 2025 15:27
Fixing the "Verify docs" job and running `v fmt` for the new
version.
This replaces the existing Earley parser (which is O(n^3)) with a LALR parser
using Yacc which is an ideal O(n). Even with very short SQL statements, the
existing parser was _really_ slow, so I had to build a query cache as bandaid,
but that has also been removed now.

This refactoring was made possible by adapting yacc from a Go implementation
here: https://github.com/elliotchance/vyac. However, in keeping with the promise
of this repo being completely written in V, the source has been copied to this
repo.

Other notable and breaking changes:

1. Not sure how this worked before, but the query may not specify a catalog in
identity chains (for example, `catalog.schema.table`). The catalog must be set
using `SET CATALOG`.
2. Syntax error messages will be slightly different, but should be a little more
helpful.
3. There are some ambiguities with the SQL grammar, such as trying to decode
what `x IS NOT TRUE` means or differentiating between `COUNT(expr)` vs
`COUNT(*)` due to lookahead limitations. Some special tokens for combinations of
operators and keywords have had to be added for known edge cases, but there are
many remaining conflicts. I suspect these conflicts don't matter as ambiguous
paths should still yield valid results, so these warnings have to be ignored for
now.
4. Fixes a very minor bug where string literals in VALUES might be treated as
`VARCHAR` instead of `CHARACTER` in some cases.
5. Renamed "std_" files with their position number in the standard. This helps
for grouping similar sections and makes lookups easier.
When an index lookup occurs as part of a DELETE, it was not stripping
the qualified identifiers in the row necessary for storage to find the
rows.

This did not effect the equivilent UPDATE, but I have add an extra
test for that anyway.

Fixed elliotchance#200
There were a few minor cases that were already implemented, but did not have specific tests.

SQL E021
SQL E021-10
SQL E021-12
@daniel-le97
Copy link
Copy Markdown
Author

@daniel-le97 any update on this? You can avoid the rebase entirely and just put the new files, it would look like this: #209

I apologize! I have not had time to check github or even the V discord in a while, due to job changes. I wasn't 100% sure on what you were asking and attempted to rebase, but i did not know what i was doing because i have not rebased before. I will look into this further tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support for builtin orm

3 participants