[google-appengine] Re: Are datastore Ids unique across all namespaces?

[NP]

Thanks for your response. And yes, I was referring to the numeric id.

In case it wasn't clear from my post, I actually want the ids to be unique. 
I was just trying to confirm that it is.

The reason I would prefer the ids are unique is because I have seeded data 
which all my users can use. The users can then in turn create entities for 
their application which are saved with a namespace for the user. Since each 
user basically has access to 2 namespaces (the default or blank namespace 
which contains my seeded data and the namespace for their app), I would 
like to search for entities by just their numeric ids. If I find the 
record, I then check the namespace associated with the corresponding key. 
For this to work, the ids need to be unique across all namespaces.



On Friday, June 14, 2019 at 7:06:48 PM UTC-7, Harmit Rishi (Cloud Platform 
Support) wrote:
>
> In order to effectively address your question, I would like to take a 
> moment and explain the characteristics of a Entity 
> . Each entity 
> within Datastore has a key that uniquely identifies it. The key (as you 
> provided) consists of the following components: 
>
> 1. Namespace of the entity
> 2. The kind 
> 
>  
> of entity (categorized for queries)
> 3. An Identifier 
> 
>  
> for the individual entity (can be a key name string or a integer numeric 
> id.)
>
> I will be assuming that you are referring to the integer numeric id for 
> your question. 
>
> As far as having two of the same numeric ID's goes, indeed it is possible 
> and this can be done by having your application assign their own numeric 
> IDs manually to the entitles being created. However, as indicated in the 
> documentation here 
> ,
>  
> "there is nothing to prevent a Datastore mode database from assigning one 
> of your manual numeric IDs to another entity". You will have to implement 
> the *allocateids() 
> *method
>  
> within your application which will allow you to obtain a block of IDs in 
> order to avoid the conflict mentioned above.
>
> Also, since you mentioned that "Datastore is the one automatically 
> generating the ids", the documentation found here 
> 
>  states 
> that the "automatic ID generator will keep track of IDs that have been 
> allocated" and that Datastore "will avoid reusing them for another entity".
>
> Therefore to sum it all up. Yes, you can achieve the goal you want. 
> However, it would be a good idea to implement the best practices for it as 
> well such as: manually assigning Ids with implementing *allocateids() 
> *
> . 
>
> I hope this helps!
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/58ed4348-39d1-4888-8b84-1fc2c45289e4%40googlegroups.com.

[google-appengine] Re: Are datastore Ids unique across all namespaces?

['Harmit Rishi (Cloud Platform Support)' via Google App Engine]

In order to effectively address your question, I would like to take a 
moment and explain the characteristics of a Entity 
. Each entity 
within Datastore has a key that uniquely identifies it. The key (as you 
provided) consists of the following components: 

1. Namespace of the entity
2. The kind 

 
of entity (categorized for queries)
3. An Identifier 

 
for the individual entity (can be a key name string or a integer numeric 
id.)

I will be assuming that you are referring to the integer numeric id for 
your question. 

As far as having two of the same numeric ID's goes, indeed it is possible 
and this can be done by having your application assign their own numeric 
IDs manually to the entitles being created. However, as indicated in the 
documentation here 
,
 
"there is nothing to prevent a Datastore mode database from assigning one 
of your manual numeric IDs to another entity". You will have to implement 
the *allocateids() 
*method
 
within your application which will allow you to obtain a block of IDs in 
order to avoid the conflict mentioned above.

Also, since you mentioned that "Datastore is the one automatically 
generating the ids", the documentation found here 

 states 
that the "automatic ID generator will keep track of IDs that have been 
allocated" and that Datastore "will avoid reusing them for another entity".

Therefore to sum it all up, Yes you can achieve the goal you want. However, 
it would be a good idea to implement the best practices for it as well such 
as: manually assigning Ids with implementing *allocateids() 
*
. 

I hope this helps!

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/8cef0d63-0f78-44b0-838a-06edd79ed05f%40googlegroups.com.

Re: [google-appengine] Re: Future of dev_appserver.py - deprecated?

['Andrew Gorcester' via Google App Engine]

We don't have a replacement for that functionality yet, but I'll record
that that's a missing link for people migrating. Thank you!

On Fri, Jun 14, 2019 at 3:02 PM Nicolas Grilly 
wrote:

> On Friday, June 14, 2019 at 11:10:21 PM UTC+2, Andrew Gorcester wrote:
>>
>> If you don't mind me asking, what are the features of dev_appserver.py
>> that are still useful with the newer runtimes, which do not have App
>> Engine-specific APIs and client libraries that dev_appserver was originally
>> intended to mock and emulate?
>>
>
> dev_appserver.py seems still useful to emulate dispatch.yaml and static
> handlers locally. Is there an alternative?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/e827acfd-b148-4d49-a8d8-da676e9c79f4%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CANtYgFJvgea0PLXyRvcXP%3DDg-Lhoo2VDUXiVfNKT%2BYMxR%2BBCBg%40mail.gmail.com.

Re: [google-appengine] Re: Future of dev_appserver.py - deprecated?

[Nicolas Grilly]

On Friday, June 14, 2019 at 11:10:21 PM UTC+2, Andrew Gorcester wrote:
>
> If you don't mind me asking, what are the features of dev_appserver.py 
> that are still useful with the newer runtimes, which do not have App 
> Engine-specific APIs and client libraries that dev_appserver was originally 
> intended to mock and emulate?
>

dev_appserver.py seems still useful to emulate dispatch.yaml and static 
handlers locally. Is there an alternative?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/e827acfd-b148-4d49-a8d8-da676e9c79f4%40googlegroups.com.

Re: [google-appengine] Re: Future of dev_appserver.py - deprecated?

['Andrew Gorcester' via Google App Engine]

The recommended alternative is to use what is idiomatic for your framework
or other development process, as you would outside of Google Cloud. This is
now possible because we no longer require the use of App Engine-specific
APIs, handlers definitions, etc. However, dev_appserver.py did have some
features beyond emulating App Engine APIs and processing handlers that some
people have integrated into their workflows, so if this new approach
doesn't work well for you, please let us know where the pain points are.

On Fri, Jun 14, 2019 at 2:10 PM James Crowley 
wrote:

> If there are alternatives I'm missing this would be awesome? The feedback
> cycle is super slow when testing Google cloud specific code when it takes
> 30 seconds+ to update a running app (and that's ignoring the downsides of
> only being able to work online)
>
> Thanks
>
> J
>
> On Friday, 14 June 2019 01:32:52 UTC+2, James Crowley wrote:
>>
>>
>> Am I right in inferring that dev_appserver.py is on the way to being
>> deprecated, given the later language versions are not supported?
>>
>> I've tripped up trying to use it in the php7 environment - it prompts me
>> to provide a --php_executable argument for php72 environments (making me
>> think it was supported), but then doesn't seem to actually support the
>> environment ("The url "/" does not match any handlers." which goes away
>> when you use the php55 app.yaml syntax for specifying handlers rather than
>> the single entrypoint parameter)
>>
>> I then noticed it's not mentioned in the docs for php72/Java 11 etc at
>> all?
>>
>> Thanks!
>>
>> James
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/23ab05d6-eb3b-45f2-8282-479f7c3f14ec%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CANtYgFLGEJAHFMnAAvcfkTNYfRQVa6DnqKCEb50R1PTxbuDKGA%40mail.gmail.com.

[google-appengine] Re: Future of dev_appserver.py - deprecated?

[James Crowley]

If there are alternatives I'm missing this would be awesome? The feedback 
cycle is super slow when testing Google cloud specific code when it takes 
30 seconds+ to update a running app (and that's ignoring the downsides of 
only being able to work online)

Thanks

J

On Friday, 14 June 2019 01:32:52 UTC+2, James Crowley wrote:
>
>
> Am I right in inferring that dev_appserver.py is on the way to being 
> deprecated, given the later language versions are not supported?
>
> I've tripped up trying to use it in the php7 environment - it prompts me 
> to provide a --php_executable argument for php72 environments (making me 
> think it was supported), but then doesn't seem to actually support the 
> environment ("The url "/" does not match any handlers." which goes away 
> when you use the php55 app.yaml syntax for specifying handlers rather than 
> the single entrypoint parameter)
>
> I then noticed it's not mentioned in the docs for php72/Java 11 etc at all?
>
> Thanks!
>
> James
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/23ab05d6-eb3b-45f2-8282-479f7c3f14ec%40googlegroups.com.

Re: [google-appengine] Re: Future of dev_appserver.py - deprecated?

['Andrew Gorcester' via Google App Engine]

We're aiming to build all of our new runtimes so that they don't require
dev_appserver.py, by making them support the same APIs and idiomatic local
development practices that one would use on any platform. If you don't mind
me asking, what are the features of dev_appserver.py that are still useful
with the newer runtimes, which do not have App Engine-specific APIs and
client libraries that dev_appserver was originally intended to mock and
emulate?

On Fri, Jun 14, 2019 at 9:31 AM 'Nicolas (Google Cloud Platform Support)'
via Google App Engine  wrote:

> Hi James,
>
>
>
> Thanks for opening this thread,
>
>
>
> To answer your question you are right the dev_appserver.py
> 
> is not supported with the PHP 7.2 and PHP 7.3 runtimes.
>
>
>
> To test your app locally you can download and install PHP 7.2 or PHP 7.3
> and set up a web server.
>
>
> Dev_appserver.py will still be available for PHP 5/7
> 
> and no deprecation is planned for the moment.
>
>
>
>
>
> On Thursday, June 13, 2019 at 7:32:52 PM UTC-4, James Crowley wrote:
>>
>>
>> Am I right in inferring that dev_appserver.py is on the way to being
>> deprecated, given the later language versions are not supported?
>>
>> I've tripped up trying to use it in the php7 environment - it prompts me
>> to provide a --php_executable argument for php72 environments (making me
>> think it was supported), but then doesn't seem to actually support the
>> environment ("The url "/" does not match any handlers." which goes away
>> when you use the php55 app.yaml syntax for specifying handlers rather than
>> the single entrypoint parameter)
>>
>> I then noticed it's not mentioned in the docs for php72/Java 11 etc at
>> all?
>>
>> Thanks!
>>
>> James
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/478d514d-d1b4-46a4-9e91-9fb715cc7439%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CANtYgFJkJkRJJRqpMeCjB4LSY50oYS4TnB67TLqAgf6cbLQ9Ww%40mail.gmail.com.

[google-appengine] Started having all sorts of import errors starting June 13

[Jay]

Hi all,

python2.7 runtime

We started having all kinds of crazy import errors starting on June 13 in 
one of our projects. This is code that hasn't changed in at least a couple 
of years, suddenly we are getting the old "ImportError: cannot import name 
foo"

If I roll back to a recent version from a few days ago, all is fine. It is 
the weirdest thing. It sort of seems like an environment thing of some sort 
but I can't imagine what it would be. 

I am throwing out a feeler to see if anyone else has seen anything like 
this.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/69ea5fa4-ab92-4576-9163-9e0f5f223d76%40googlegroups.com.

[google-appengine] Re: Future of dev_appserver.py - deprecated?

['Nicolas (Google Cloud Platform Support)' via Google App Engine]

Hi James, 

 

Thanks for opening this thread, 

 

To answer your question you are right the dev_appserver.py 

 
is not supported with the PHP 7.2 and PHP 7.3 runtimes. 

 

To test your app locally you can download and install PHP 7.2 or PHP 7.3 
and set up a web server.

 
Dev_appserver.py will still be available for PHP 5/7 

 
and no deprecation is planned for the moment.





On Thursday, June 13, 2019 at 7:32:52 PM UTC-4, James Crowley wrote:
>
>
> Am I right in inferring that dev_appserver.py is on the way to being 
> deprecated, given the later language versions are not supported?
>
> I've tripped up trying to use it in the php7 environment - it prompts me 
> to provide a --php_executable argument for php72 environments (making me 
> think it was supported), but then doesn't seem to actually support the 
> environment ("The url "/" does not match any handlers." which goes away 
> when you use the php55 app.yaml syntax for specifying handlers rather than 
> the single entrypoint parameter)
>
> I then noticed it's not mentioned in the docs for php72/Java 11 etc at all?
>
> Thanks!
>
> James
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/478d514d-d1b4-46a4-9e91-9fb715cc7439%40googlegroups.com.